Reason about consistency, scale, failure modes, and production trade-offs in Java systems.
Distributed systems · design
Use the strong answer as your reference, explain it aloud in your own words, then choose how soon you want to review it again.
Interview prompt
Strong answer
Once data spans services, a single ACID transaction is no longer available, and two-phase commit is usually too slow and fragile for business workflows. Instead, keep each service's change locally atomic, publish state changes reliably with the transactional outbox, and coordinate multi-step workflows with a saga that runs compensating actions on failure. System design interviews test the same thinking at scale: clarify requirements, estimate load, choose consistency per operation, and walk through failure modes and trade-offs.
Key points
Interviewer looks for
Structure the design: requirements, scale estimates, data model, APIs, consistency choices, and failure scenarios such as a crash between steps, duplicate messages, or a compensating step that also fails.
Java example
1@Transactional
2public OrderId placeOrder(PlaceOrder cmd) {
3 Order order = orders.save(Order.pending(cmd));
4 outbox.save(OutboxEvent.of("order", order.id(), "OrderPlaced", toJson(order)));
5 return order.id(); // both rows commit or neither does
6}
7
8// Relay (or Debezium CDC) publishes outbox rows, then marks them sent.
9@Scheduled(fixedDelay = 500)
10void relay() {
11 for (OutboxEvent e : outbox.findUnsentBatch(100)) {
12 kafka.send("orders.events", e.aggregateId(), e.payload()).join();
13 outbox.markSent(e.id());
14 }
15}
16
17// Saga orchestrator step
18void onPaymentFailed(PaymentFailed event) {
19 inventory.release(event.orderId()); // compensating action
20 orders.markCancelled(event.orderId(), "payment_failed");
21}Topic interview questions
These questions are tied to this lesson. Read each question aloud, then compare your explanation with the strong answer.
Strong answer
2PC needs every participant to support it, holds locks while waiting for the coordinator, and blocks if the coordinator fails at the wrong moment. That couples availability and latency of all services, so most systems prefer local transactions plus sagas and eventual consistency.
Strong answer
The service writes its business change and an event row to an outbox table in the same local transaction. A separate relay or CDC tool publishes those rows to the broker and marks them sent. Events are never lost or published for rolled-back changes, though delivery is at-least-once so consumers stay idempotent.
Strong answer
In orchestration a coordinator tells each service what to do next and tracks the saga state, which is easier to reason about and monitor. In choreography services react to each other's events with no central controller, which reduces coupling to one component but makes the overall flow harder to see and change.
Strong answer
During a network partition a distributed system must choose between staying available and staying consistent for the affected data. Outside partitions the more practical trade-off is latency versus consistency. Real designs choose per operation rather than labelling the whole system CP or AP.
Strong answer
Clarify functional and non-functional requirements, estimate peak requests and data size, then design the API, data model, and flow. Protect inventory with atomic decrements or reservations, absorb spikes with queues and rate limits, cache read-heavy catalog data, and discuss failures, idempotency, and monitoring explicitly.
How well do you know this?
Your review choice is saved locally and synced to your learner profile when signed in.