Design a Distributed Cache

In IBM's senior loop this design rarely arrives as "design a distributed cache" on a blank board. It usually comes in two moves. First the interviewer asks you to implement a Premium question in code, correct and O(1), the classic hash map plus doubly linked list. Once that works, the interviewer says now make it distributed. One box can't hold the whole working set or take the load, so how do many of them act as one cache? IBM likes that climb from a single class to a fleet inside one question, and it's why the LRU from the coding round comes back here.

Keep the scale honest. This is an enterprise cache that fronts a database, a Db2 instance or a service's own store, and it exists because that database can't serve the read rate the application throws at it. Most of the design pressure comes from the fleet changing shape, more than from raw throughput. A scale-up adds a node, a node dies at three in the morning, or a deploy restarts the whole tier, and any of those can turn a warm cache cold. A cold cache sends its full read load straight at the database it was protecting. IBM cares far more about how gracefully the cache gets through that than about whether it can serve billions of reads.

The IBM angle

IBM's version of this question is a low-level design that grows into a high-level one under you, and both halves are graded. Candidate reports describe the same two-round arc again and again. In the first technical round you implement a Premium question by hand, bug-free and O(1). In a design round the interviewer picks that same structure back up and scales it across machines. Come ready to write the single-node cache from memory, the map for lookup and the doubly linked list for recency. Then defend the distributed decisions on top: how keys map to nodes, what happens to that map when the fleet resizes, and what consistency a cache actually owes its callers.