How do you approach Design Bounded Blocking Queue (Single-Threaded Model)?

Back the queue with a FIFO structure (a deque is ideal) plus the fixed capacity. There is no locking to do because everything runs on one thread.

What is the time complexity of Design Bounded Blocking Queue (Single-Threaded Model)?

Time complexity: O(1) per operation.. Space complexity: O(capacity) for the buffer..

What are common mistakes on Design Bounded Blocking Queue (Single-Threaded Model)?

Hitting the stated complexity for one operation by making another linear. These problems grade every operation. Keeping two structures in sync but updating only one of them on the delete path. Skipping the capacity edges: insert when full, read when empty.

gitGood.dev

← Back to problems

Design Bounded Blocking Queue (Single-Threaded Model)

MediumObject-Oriented Design

Description

Design a bounded queue with a fixed `capacity`. A real bounded blocking queue blocks producers when full and consumers when empty using concurrency primitives. **Here you implement a single-threaded simulation of the data structure - there is no real blocking or threading.** Instead of blocking, a full enqueue or an empty dequeue simply reports failure. - `enqueue(value)` adds an element to the back; returns `true` if it was added, or `false` if the queue is already at capacity. - `dequeue()` removes and returns the element at the front, or `-1` if the queue is empty. - `size()` returns the current number of elements. Implement the function `boundedQueue(capacity, operations)` where `capacity` is the maximum size and `operations` is a list of `[op, ...args]`: `["enqueue", v]`, `["dequeue"]`, `["size"]`. Return the list of results, one per operation (use null for operations that return nothing - here every operation returns a value).

Example 1

Input: capacity = 2, operations = [["enqueue",1],["enqueue",2],["enqueue",3],["size"],["dequeue"],["dequeue"],["dequeue"],["size"]]

Output: [true, true, false, 2, 1, 2, -1, 0]

Example 2

Input: capacity = 1, operations = [["size"],["enqueue",5],["enqueue",6],["dequeue"],["enqueue",7],["dequeue"]]

Output: [0, true, false, 5, true, 7]

Example 3

Input: capacity = 3, operations = [["enqueue",10],["enqueue",20],["enqueue",30],["dequeue"],["enqueue",40],["size"]]

Output: [true, true, true, 10, true, 3]

Constraints

1 <= capacity <= 1000. Enqueued values are integers. At most 5000 operations. All operations run on a single thread, in order; there is no concurrency to reason about.

Design Bounded Blocking Queue (Single-Threaded Model): approach, complexity and pitfalls

A medium design problem, graded against 6 test cases (3 of them hidden).

The pattern: Design

Build a working data structure to an API - LRU caches, rate limiters, and iterators.

Reach for it when you see: "Design a class supporting these operations in O(1)" - an API rather than a single function.

More Designproblems →

If you are stuck

Show the 3-step hint ladder

Back the queue with a FIFO structure (a deque is ideal) plus the fixed capacity. There is no locking to do because everything runs on one thread.
enqueue returns false instead of blocking when size has reached capacity; dequeue returns -1 instead of blocking when the queue is empty.
size is just the current element count. Process the operations in order and append exactly one result for each.

The optimal approach

Show the approach: The approach

Because this is a single-threaded model, the 'blocking' semantics collapse into simple full/empty checks - no locks, conditions, or threads. Use a deque as the FIFO buffer. `enqueue` appends and returns true only while `size < capacity`, returning false otherwise. `dequeue` pops the front and returns it, or returns -1 when empty. `size` returns the current length. Using a deque keeps front removal O(1).

Time: O(1) per operation.
Space: O(capacity) for the buffer.

The full reference solution in every supported language stays in the editor above - reveal it there once you have had a real attempt.

What the tests check

Read off this problem's own test suite, so these are the cases a submission actually has to survive.

Single element. A one-element case is included. Two-pointer and window solutions frequently return the wrong thing when the two indices start out equal.

Common Design mistakes

These apply to the pattern as a whole, not just this problem.

Hitting the stated complexity for one operation by making another linear. These problems grade every operation.
Keeping two structures in sync but updating only one of them on the delete path.
Skipping the capacity edges: insert when full, read when empty.