Design Disk-Based Inventory Serving
Design the software for a single machine that serves inventory requests. The machine has spinning disks only — no SSD — and a small amount of RAM.
Records are keyed by item id and hold an available quantity, a reserved quantity, and descriptive metadata. The service must support reads, updates, and conditional reservations: reserve one unit only if the available quantity is greater than zero, without ever overselling — including across a crash.
Discuss the on-disk data layout, the indexing strategy, what you cache and why, the write path, the read path, how a reservation stays atomic and durable, recovery, and how you keep latency acceptable given what a disk head can do.
Hints
Hint 1
Start from the physics: a 7200 rpm disk does roughly 100–150 random operations a second (8–10 ms each) but 100+ MB/s sequentially. The design goal is at most one seek per read and zero seeks per write.
Hint 2
Separate what changes from what is big. Quantities are a few bytes and change constantly; metadata is large and nearly static. Fixed-width counter records can be addressed directly by offset, so they need no in-memory index at all.
Hint 3
Writes go to an append-only log with group commit and are applied to the data file later in one sorted sweep. A reservation is a check against the in-memory value plus a log append, owned by a single writer per partition.
Asked at
Sign in to talk to the interviewer — ask what's in scope, what scale to design for, or for a nudge when you're stuck. Conversations save to your account.