Implement a thread-safe producer–consumer buffer
Bounded Blocking Buffer with Shutdown and Timeouts
You are asked to design and implement a thread-safe, fixed-capacity producer–consumer buffer that supports multiple producers and consumers.
Functional Requirements
-
FIFO ordering of items.
-
Configurable capacity N.
-
put(item):
-
Blocks when the buffer is full.
-
A timed put(item, timeout) variant that times out if space does not become available in time.
-
take():
-
Blocks when the buffer is empty.
-
A timed take(timeout) variant that times out if no item becomes available in time.
-
shutdown():
-
Unblocks any waiting producers/consumers.
-
Rejects new puts after shutdown is invoked.
-
After shutdown, consumers may still take remaining items; if the buffer is empty, take should not block.
Non-Functional and Correctness Requirements
-
Thread-safe for multiple producers and consumers.
-
Prevent race conditions, deadlocks, and lost wakeups.
-
Discuss fairness and performance trade-offs.
-
Analyze time and space complexity.
-
If time permits: compare a lock-based design (mutex + condition variables) to a lock-free approach.
Assume a Java-like API and execution model (mutex/condition variables, interrupts, and timed waits). You may use a circular array for FIFO ordering.
Constraints & Assumptions
-
Preserve the scope, facts, inputs, and requested outputs from the prompt above.
-
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
-
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.
Clarifying Questions to Ask
-
Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
-
State explicit assumptions before making sizing or architecture decisions.
-
Prioritize the functional path first, then address reliability, security, observability, and rollout.
What a Strong Answer Covers
-
A scoped requirements summary with concrete non-goals and success metrics.
-
API, data model, architecture, consistency, capacity, and operations.
-
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
-
A validation, monitoring, migration, and launch plan appropriate for the risk level.
Follow-up Questions
-
What breaks first at 10x traffic or data volume?
-
How would you degrade gracefully during dependency failures?
-
What metrics and alerts would prove the design is healthy after launch?