LFU Cache
Reported by candidates from Blinkit's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Blinkit reported this LFU Cache question in September 2026, and the stated O(1) per operation requirement is what kills the lazy approach. With up to 2 * 10^4 commands and capacity up to 3000, scanning for the minimum frequency on every eviction is exactly what the OA is built to punish. This is a design problem. You build a structure, you don't find a clever formula. If you've seen LRU, you're halfway there. If you blank on the wiring between frequency buckets, StealthCoder is the invisible safety net that can hand you the structure live.
The problem
Process commands on an initially empty least-frequently-used cache with positive integer capacity. put key value inserts a new key or updates an existing key. get key returns the stored value, or -1 when the key is absent. For this exercise, assume a successful get and a put that updates an existing key each increase that key's frequency by one and make it most recently used within its new frequency. A new key starts with frequency one. When a new insertion would exceed capacity, evict the key with the smallest frequency. Break a frequency tie by evicting the least recently used key. Return the results of all get commands in order. Each operation should run in average O(1) time. Function processLfuCache(capacity: int, operations: String[]) → int[] Examples Example 1 capacity = 2 operations = ["put 1 1","put 2 2","get 1","put 3 3","get 2","get 3","put 4 4","get 1","get 3","get 4"] return = [1,-1,3,-1,3,4] Reading key 1 raises its frequency, so key 2 is evicted first. Later keys 1 and 3 tie on frequency, and key 1 is least recent. Example 2 capacity = 1 operations = ["put 7 5","put 7 8","get 7","put 9 4","get 7","get 9"] return = [8,-1,4] Updating key 7 changes its value and frequency. Inserting key 9 into a one-entry cache then evicts key 7. Constraints 1 <= capacity <= 3000. 1 <= operations.length <= 2 * 10^4. Each command is exactly get key or put key value. Keys and values fit in signed 32-bit integers. At least one command is get.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The trick is two hash maps plus a tracked minimum frequency. One map goes from key to value and frequency. The other goes from frequency to an ordered set of keys, oldest first, like a linked hash set. On get or an updating put, remove the key from its bucket, bump its frequency, and append it to the next bucket. If the old bucket was empty and it equaled the minimum, increment the minimum. On a new insert at capacity, evict the oldest key in the minimum-frequency bucket, then set the minimum to 1. The common pitfall is forgetting that a put on an existing key also raises frequency here. Another is resetting the minimum wrongly. Capacity is at least 1, so you don't need a zero-capacity guard. If the bucket wiring falls apart mid-assessment, StealthCoder is your hedge 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 LFU 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
This OA pattern shows up on LeetCode as lfu cache. If you have time before the OA, drill that.
You've seen the question.
Make sure you actually pass Blinkit's OA.
Blinkit 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.
LFU Cache FAQ
What's the trick to LFU Cache in O(1)?+
Keep a key-to-entry map and a frequency-to-ordered-keys map, plus a minFreq variable. Every touch moves a key from one bucket to the next. Eviction pops the oldest key from the minFreq bucket. Ordered buckets handle the LRU tiebreak without any scanning.
How hard is this Blinkit LFU Cache question really?+
It's a hard-tier design problem, but the logic is mechanical once you know the structure. The difficulty is bookkeeping, not insight. Most failures come from minFreq updates and forgetting that updating put also bumps frequency.
Does a put on an existing key change frequency here?+
Yes. The problem states a put that updates an existing key increases its frequency by one and makes it most recently used within the new frequency. Example 2 shows this: key 7 gets updated, then evicted when key 9 arrives at capacity 1.
How do I prepare for this in 48 hours?+
Write it from scratch twice. First do LRU with a hash map and doubly linked list, then extend to frequency buckets. Test against both examples by hand. Focus on the minFreq transitions, since that's where bugs hide.
Can I just use a priority queue?+
Not for O(1). A heap gives O(log n) per operation and makes the recency tiebreak awkward. With 2 * 10^4 operations it might pass on time, but the problem explicitly asks for average O(1), so use the bucket approach.