Single-Flight Chunk Cache
Reported by candidates from Modal's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Modal's September 2026 OA has a cache simulation that looks easy until you ship your first attempt. The usual mistake is counting in-flight fetches against capacity, or forgetting to refresh recency on a HIT. It's an LRU cache with a single-flight twist: one fetch per key, everyone else gets WAIT. The real work is bookkeeping, not algorithms. If you blank mid-assessment, StealthCoder runs invisibly on your desktop and can hand you the structure while the proctor sees nothing. But you can learn the shape tonight.
The problem
Simulate a byte-capacity cache for network image chunks. Process operations in order: GET key size: return HIT key and refresh recency when cached; return WAIT key when the same key is already being fetched; otherwise start one fetch, remember its size, and return FETCH key. DONE key: return IGNORED key when no fetch is active. Otherwise finish that fetch. If its size exceeds total capacity, do not cache it and return TOO_LARGE key. Otherwise evict least-recently-used cached chunks until it fits, cache it as most recent, and return STORED key. When eviction occurs append EVICT key1,key2 in eviction order. Only completed chunks occupy cache capacity. An operation is the recency clock; lexicographically smaller keys break an otherwise impossible equal-clock tie. Function processChunkCache(capacity: int, operations: String[]) → String[] Examples Example 1 capacity = 10 operations = ["GET a 6","GET a 6","DONE a","GET a 6"] return = ["FETCH a","WAIT a","STORED a","HIT a"] The second miss waits for the active fetch, and the later request is a cache hit. Example 2 capacity = 10 operations = ["GET a 6","DONE a","GET b 7","DONE b"] return = ["FETCH a","STORED a","FETCH b","STORED b EVICT a"] Storing b evicts least-recently-used a because both chunks do not fit. Constraints 0 <= capacity <= 1000000000 1 <= operations.length <= 2000 Keys contain letters, digits, dash, or underscore and sizes are nonnegative integers.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The pattern is design: an ordered map for the LRU plus a separate map for active fetches. Keep them apart. Only completed chunks live in the LRU and count toward used bytes. GET checks cache first (HIT, refresh recency), then the in-flight map (WAIT), otherwise records the size and returns FETCH. DONE on a key with no active fetch returns IGNORED. If the size exceeds total capacity, return TOO_LARGE and cache nothing, and don't evict anything either. Otherwise pop from the least-recent end while used + size > capacity, collecting evicted keys, then insert as most recent. Append the EVICT list to the STORED output only when something was evicted. Pitfalls: evicting before checking TOO_LARGE, a zero-capacity cache, and a zero-size chunk. With 2000 operations, even a linear scan works. StealthCoder is your hedge if the ordering rules slip on the live OA.
If you see this problem in your OA tomorrow, the play is to recognize the pattern in 30 seconds. StealthCoder buys you that recognition.
You can drill Single-Flight Chunk Cache cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. Built by an Amazon engineer who passed his OA cold and still thinks the filter is broken.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Modal's OA.
Modal reuses patterns across OAs. Built by an Amazon engineer who passed his OA cold and still thinks the filter is broken. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Single-Flight Chunk Cache FAQ
What's the trick in the Modal single-flight chunk cache problem?+
Keep two structures: an ordered LRU of completed chunks and a map of active fetches with their sizes. In-flight fetches never take capacity. Most wrong answers mix the two or forget that a HIT refreshes recency.
How hard is this OA really?+
Medium on difficulty, high on detail. No clever algorithm is needed, just careful rule following. With 2000 operations, performance isn't the issue. Correct output strings and ordering are what fail people.
What happens when a chunk is larger than capacity?+
DONE returns TOO_LARGE for that key. The chunk is not cached and nothing gets evicted. Check this before any eviction loop, or you'll wipe the cache for nothing. Capacity 0 falls into this case for any positive size.
How should the EVICT suffix be formatted?+
Append it to the STORED result only when at least one chunk was evicted, as in STORED b EVICT a. Multiple keys are comma-separated in eviction order, oldest first, like EVICT key1,key2.
How do I prepare for this in 48 hours?+
Write an LRU cache from scratch with an ordered map or a list plus hash map. Then add the in-flight map and trace both examples by hand. Test edge cases: IGNORED, TOO_LARGE, zero capacity, repeated GET after DONE.