Software Engineer interview question
What makes a distributed system difficult?
Distributed systems are difficult because messages are delayed, duplicated, reordered, or lost and nodes fail independently. Correct design makes timeouts, retries, idempotency, consistency, ownership, and partial failure explicit.
Direct answer
What a strong answer covers
How it works
On one machine a function call either returns or throws. Across a network the caller can never distinguish a lost request, a slow reply, and a crashed server, so every remote call has a timeout and every retry might duplicate work. Clocks disagree, so ordering by timestamp is unreliable. Nodes fail independently, so the system must decide what to do when only some of them respond, which forces trade-offs between consistency and availability during partitions. The discipline is making these facts explicit: idempotent operations, clear ownership of each piece of data, and tests that inject failure.
Example
A payment service called a ledger service that timed out after writing the entry; the naive retry created a double debit. The fix gave every ledger write a client-generated ID so the second attempt was recognised, and a chaos test that drops 5 percent of responses now runs in CI to keep the guarantee honest.
Common mistakes
- Assuming a timeout means the operation did not happen.
- Using wall-clock timestamps from different machines to order events.
- Designing for the happy path and discovering partial failure in production.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.