Posts

Consistency in distributed systems refers to whether different parts of the system observe the same data at the same time. In strong consistency, every read returns the most recent write, so the system behaves like a single source of truth. In eventual consistency, temporary inconsistencies are allowed, but the system guarantees that all replicas will converge to the same value over time. In practice, we don’t apply strong consistency everywhere because it hurts latency and availability. Instead, we apply strong consistency only to critical data that affects correctness, such as ride-driver assignment in Uber, and use eventual consistency for high-throughput or latency-sensitive data like driver location updates.

Design Doc: Posting to My Hugo Blog Directly from iPhone 1. Problem I wanted a low-friction way to publish to my blog from my iPhone. The original blog setup was simple: content lives in Markdown inside a Hugo repo GitHub Actions builds and deploys the site GitHub Pages serves the final static output That setup is good for reliability, but not good for writing on mobile. Editing Markdown through GitHub’s mobile UI technically works, but it is still a repo workflow, not a writing workflow. ...

我爱恬

Relational DB vs NoSQL — Interview Answer Template (with QPS Details) 1. Throughput & Scalability A relational database like MySQL can handle moderate QPS well. Rough Numbers (rule of thumb, varies by setup): Single MySQL instance ~1K – 5K QPS (typical production range) With read replicas Reads can scale to 10K+ QPS With sharding Can scale to 100K+ QPS, depending on number of shards However, sharding introduces additional complexity: Choosing a good shard key Avoiding hotspot partitions Handling cross-shard queries Rebalancing data Example Tradeoffs: Shard by userId ...

🧠 Rebuilding Trust in Effort — A Practical Framework 🎯 Core Insight You’re not someone who lacks discipline or ability. You lost trust in effort. From some of your past experiences, your brain learned: “Effort does not guarantee results” So later, you subconsciously held back to avoid disappointment. ⚠️ The Real Problem It’s not: Laziness Lack of ambition It is: A broken feedback loop between effort and reward 🔁 What You Need to Rebuild You need to re-establish this loop: ...

Lessons Learned from My Product Discovery Journey Key Lessons 1. Start with a minimal product scope I learned that I should begin with a small and clear set of functional requirements instead of adding extra features too early. In system design interviews, simple is usually better than broad. I should focus first on the core user needs and avoid introducing features that are not explicitly required. 2. Always call out non-functional requirements early One of my biggest takeaways is that I need to explicitly mention non-functional requirements such as: ...

Change Data Capture (CDC) Summary Purpose: Track and propagate data changes (insert, update, delete) from a source to downstream systems. Write-Ahead Log (WAL): In relational databases (e.g., PostgreSQL), all changes are logged before being applied. CDC reads from the WAL to capture changes. NoSQL: In systems like DynamoDB, item-level streams capture changes in a similar fashion. Pipeline Actions: Detect changes. Send to downstream systems. Examples: replicate to read replicas, sync to a search index (Elasticsearch), or forward to Kafka. Key Considerations: ...

Learning 🎬 Video Upload & Moderation System (TikTok-style) 1. Functional Requirements Creators can upload videos Users can view videos Reviewers can moderate videos Users get notified if content is banned 2. Non-Functional Requirements High availability (eventual consistency acceptable) High throughput for uploads and reads Low latency for video playback Scalable for viral (hot) content 3. High-Level Architecture Upload Flow Client → API Gateway → UploadService → S3 ↓ Kafka Read Flow User → CDN → S3 ...

10 System Design Tips (Senior-Level) April 8, 2026 Yutong Jin 🧠 System Design Key Principles 1. Start with Functional Requirements Clearly define what the system needs to do: Core APIs (read/write flows) User interactions Edge cases 💡 Tip: Do NOT spend too long here — 2–3 minutes is enough in interviews. 2. Identify the Core Bottleneck Early Before designing, ask: What is the expected QPS? Where will the system break first? Common bottlenecks: ...

System Design Interview Feedback (Calendar System) 🟢 Overall Feedback Functional design was mostly correct Reminder workflow was well structured High-level direction was solid Some gaps existed but were mostly trivial 🧩 Requirements & Scoping ✅ Strengths Covered core functional requirements API design was reasonable Non-functional requirements were acceptable ⚠️ Improvements Did not explicitly capture recurring events early Impacts storage, reads, and notifications 🧱 Data Modeling & Schema ✅ Strengths Entity design was reasonable Core fields identified correctly ⚠️ Improvements Avoid defining full schema too early Do schema after high-level design Partitioning strategy needs improvement 🧠 Partitioning ❌ Current approach Partition by event ID ⚠️ Problem Optimizes writes, not reads ✅ Recommended Partition by time (start time / next start time) 💡 Reason Main read paths: GET events by date range Scheduler scans Time-based partitioning narrows scan range and improves performance 🔁 Recurring Events Design ❌ Problematic approach Pre-populating all occurrences Issues Data duplication Infinite recurrence problems Hard to update or cancel ✅ Recommended Store recurrence rules and frequency Return to client Let client compute occurrences 💡 Benefits Avoid duplication Better scalability Easier maintenance 🔔 Notification / Scheduler Design ✅ Strengths Scheduler + queue architecture was correct Recognized pattern: calendar = distributed scheduler ⭐ Strong point Correct use of delayed queue (e.g., SQS) 🧠 System Pattern Recognition User provides data now, system acts later → scheduler pattern ...