How the interviewer opens it
“Design a service that coordinates atomic commits across independent data stores. The service must recover correctly from coordinator crashes, store failures, and network partitions.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Atomicity contract
- Store capabilities
- Client workflow
- Scale and request mix
- Latency
- Consistency and availability
- Deployment and durability
- Failure model
- Records and retention
- Excluded features
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Coordinate atomic commits across supported stores
- Return a durable commit or abort outcome
- Recover unfinished transactions after faults
- Handle repeated requests without changing a final outcome
Usually out of scope
- Support for stores without durable prepare
- Global serializability and cross-store snapshots
- Business compensation
- Distributed query execution
What interviewers ask about
- Transaction outcome
- Each store controls its own writes. The coordinator must establish one final outcome without one atomic operation across all stores.
- Coordinator recovery
- A crash can separate a durable decision from its delivery. A former coordinator can also resume after another process takes control.
- Store outages
- A prepared store holds resources but cannot infer the outcome from silence. Long outages can exhaust capacity even when atomicity remains correct.
- Repeated requests and old records
- Repeated messages must not repeat local effects. Record removal must not erase an outcome that an offline store or old request still needs.
Common mistakes
- The coordinator returns commit before it stores a durable decision.
- Prepared stores abort when a local timer expires.
- The design treats a client timeout as an abort result.
- The design uses replication to claim that atomic commit never blocks.
- The design assumes every store supports durable prepare.
- The design confuses atomic commit with global serializability.
The bar by level
- Senior (L5/E5)
- Explains recovery at each crash boundary. Protects decisions during failover. Defines safe repeated commands, participant recovery, prepared resource limits, and admission limits.
- Staff (L6+/E6+)
- States the safety argument across ownership changes and partitions. Defines record retirement and replay rules. Quantifies resource costs. Separates coordinator availability from transaction progress.