# Design a distributed transaction coordinator: system design interview question

> Atomic commits across stores: durable decisions, crash recovery, uncertain outcomes, and progress limits during partitions.

Source: https://sysround.com/questions/design-distributed-transaction-coordinator
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## 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."

## 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

## 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 probe

### 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:** Explains recovery at each crash boundary. Protects decisions during failover. Defines safe repeated commands, participant recovery, prepared resource limits, and admission limits.
- **Staff+:** States the safety argument across ownership changes and partitions. Defines record retirement and replay rules. Quantifies resource costs. Separates coordinator availability from transaction progress.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=distributed-transaction-coordinator


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.