Layer 3 · Go deeper · 6 min
Go deeper
Size it, build it, then make the calls an interviewer will push you on.
Build-up · 5 steps
Watch a retry reorder one order
Two events for order 42 on a standard queue with two competing workers and a 30-second visibility timeout. Drawn to show order, not to scale.
Step 1 of 5
Two events, two workers
At 0 s, m1 (PAID) goes to Worker 1 and m2 (SHIPPED) goes to Worker 2. Competing consumers take whatever is next.
4 interview moments
You’re the candidate
The interviewer pushes on the hard parts. Pick an approach and see how it holds up.
Deep dive 1 of 4
Interviewer
“Each wallet’s events must apply in order, and one stuck wallet mustn’t stall anyone else. Kafka partitions or SQS FIFO message groups?”
Your move. Pick an approach:
Deep dive 2 of 4
Interviewer
“A RefundIssued for one wallet fails every time because of a ledger bug. What does the consumer do?”
Your move. Pick an approach:
Deep dive 3 of 4
Interviewer
“A tense cricket chase sends 2,000 events a second for one match ID, and the handler manages 500. What do you do?”
Your move. Pick an approach:
Deep dive 4 of 4
Interviewer
“You have 10 partitions, 100,000 keys and a 50 ms handler, so throughput is too low. How do you get more parallelism?”
Your move. Pick an approach:
Build-up · 5 steps
A version check in four events
The single writer numbers each order’s events. The consumer stores the last version it applied and compares every arrival against it.
Step 1 of 5
Stored at version 7
Order 42’s row says version 7, SHIPPED. The producer increments the version in the same transaction as each change.