Design an event-driven order processing system for an e-commerce site. Payment, inventory, and shipping are separate services.
What they are really testing: Whether you can reason about ordering, idempotency, and partial failure rather than just drawing boxes connected by a queue.
A real interview question
Design an event-driven order processing system for an e-commerce site. Payment, inventory, and shipping are separate services.
What most people say
drag me
“The order service publishes to a queue and payment, inventory, and shipping each subscribe and do their part.”
It stops exactly where the hard part starts. It says nothing about what happens when payment succeeds and inventory fails, which is the entire reason this question gets asked.
The follow-ups they ask next
The payment provider times out. Did the charge happen or not?
Answer with idempotency keys and a reconciliation job that queries the provider before retrying, never a blind retry.
Two events for the same order arrive out of order. What now?
Talk about a version or sequence number on the order aggregate and rejecting stale transitions, not about hoping the broker orders them.
How do you debug an order stuck for two hours?
Correlation id on every event, a state machine you can query, and a dead letter queue you actually monitor.
What the interviewer is listening for
- Uses the transactional outbox instead of writing to the database and the broker separately
- Makes every consumer idempotent on a business key
- Defines a compensating action for each saga step
- Names the oversell risk out loud instead of pretending it does not exist
What sinks the answer
- Claims a distributed transaction will keep everything consistent
- Never mentions duplicate delivery or retries
- Has no plan for an order that gets stuck
- Chooses Kafka purely because it is popular, with no reference to the load
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“I have not built a full saga in production, but here is how I would reason about it. The moment payment and inventory live in different services, I have to answer what the undo looks like, so I would start there.”
Keep going with system design
Mid
Design a log and metrics ingestion pipeline for a platform with about 200 services. Engineers need to search logs and alert on metrics.
Mid
Design an image upload and processing service for a marketplace app. Users upload photos from their phone, and we need thumbnails and a moderation check before the listing goes live. Walk me through it.
Senior
Design an analytics pipeline that produces a daily report for the leadership team by 8am. The data comes from a production database and a stream of app events.
Senior
Design a system that must never lose a message. It ingests payment notifications from a partner and each one must be processed exactly once.
Senior
We have about 50 product teams and every one of them has rolled their own pipeline. Design a CI/CD platform that all 50 can use. Take me through it.
Senior
We are moving from one shared cloud account to a proper multi-account setup. Design the landing zone.
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free