Consume inventory events without counting replays twiceLESSON 2.43 · 43 OF 43 IN CHAPTER
PART A / Coding problems and trade-offs
Step 69 of 252
LESSON 2.43 · 43 OF 43 IN CHAPTERMock interview

Consume inventory events without counting replays twice

A fulfillment dashboard tracks changes in item counts. An event e1 adds two books, while e2 removes one. Delivery may repeat e1, but that does not mean two more books arrived. Implement the in-memory consumer described below. This session does not require a database or message broker.

“A fulfillment dashboard receives events with id, item and integer delta. Redelivery is normal. Implement a consumer that returns item totals and never counts an equal event twice. Clarify which identity and ordering assumptions matter.”

Constructed 45-minute independent session. Allowed: editor, language standard library, your own tests. Do not open assessor/reference pages. Prerequisites before session day: maps, complexity.

Contract Expected behavior
Input Finite sequence of {id:string,item:string,delta:integer}
Example (e1,book,+2),(e2,book,-1),(e1,book,+2) → {book:1}
Boundary Empty stream → {}; invalid field types rejected
Starting assumption Repeated ID initially has equal payload; input sequence is ordered
Excluded Database persistence and real-time distributed delivery
Diagram: Consume inventory events without counting replays twice

Restate the contract, trace the example, choose identity state and one invariant, then implement and derive tests. Explain time and retained memory. A simple correct baseline is useful, but it must fail visibly on redelivery before you replace the representation.

Diagram: Consume inventory events without counting replays twice

At minutes 15 and 30, the assessor changes the contract. Ask what changes before editing; give one counterexample to your previous design. At the end, run the exact cases you created and explain unfinished work. Expected baseline evidence is the example above, explicit duplicate behavior and a runnable empty/invalid-input check. Senior scope requires adaptation; lead scope also defines compatibility and ownership if events come from two producers. Feedback arrives only after the attempt.