
π System Design Interview Classics Β· State Machine
The states a file goes through in a sync client like Dropbox: detected, chunked, uploaded, synced, and conflict handling when two devices edit the same file.
Drawing diagramβ¦
State machine for a file in a sync client: Detected when a change is seen, Chunking into 4 MB blocks, Uploading only new blocks, Committing the new version to the metadata server, Synced. If the server has a newer version from another device it becomes Conflict and a conflicted copy is saved. Network errors move to Waiting and retry.
stateDiagram-v2 [*] --> Detected: Local change seen Detected --> Chunking Chunking --> Uploading: New blocks found Chunking --> Committing: No new blocks Uploading --> Committing: Blocks stored Uploading --> Waiting: Network error Waiting --> Uploading: Retry Committing --> Synced: Version accepted Committing --> Conflict: Server has newer version Conflict --> Synced: Conflicted copy saved Synced --> Detected: Edited again Synced --> [*]
The classic interview design for a service like bit.ly: short code generation, fast redirects from a cache, and click analytics processed separately.
How a one-to-one chat message is delivered in a WhatsApp-style system, with sent, delivered and read ticks, and push notifications when the receiver is offline.
How posts reach followers' feeds: fan-out on write for normal users, fan-out on read for celebrities, and a ranked feed built from a cache.
The core of a ride-hailing app: drivers stream their locations, a geo index finds nearby drivers, and a matching service offers the trip to the best one.
How a token bucket rate limiter decides whether to let an API request through, using Redis so all servers share the same counts.
A notification system that sends email, SMS and push messages at scale: one API, a queue per channel, user preferences, and retries.