Databricks·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Jul 2026

Summary

Databricks system design round, focused entirely on a key-value store with a configurable sliding-window QPS tracker. The question kept unfolding into more trade-off territory than I expected and I felt like I was playing catch-up the whole time.

Questions Asked (1)

Design a key-value store that supports put, delete, and an average QPS query over a configurable sliding time window. Walk through how you'd handle different window sizes, memory costs, and the trade-offs between update and query performance.

System DesignTechnical Trade-offsAlgorithms & Data Structures

Author's notes

Started fine with the ring-buffer approach for a fixed 60-second window, per-second buckets, easy.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements: define the sliding window semantics (e.g., last N seconds), expected QPS, and read/write ratio. Then propose a design that separates the key-value store (e.g., LSM-tree or hash index) from the QPS tracking mechanism, using a time-bucketed ring buffer with atomic counters for efficient windowed aggregation. Discuss trade-offs between memory, update cost, and query latency for different window sizes, and how to handle high cardinality and concurrency.

Pro tip: Emphasize that the QPS query is an aggregation over time, so pre-aggregating in fixed-size buckets (e.g., 1-second granularity) drastically reduces memory and query cost, but introduces a trade-off between accuracy and bucket size. Also mention that for very large windows, you can use a two-level approach: fine-grained buckets for recent time and coarser buckets for older time, or use probabilistic data structures like count-min sketch if approximate QPS is acceptable.

1. Clarify requirements and constraints

Ask about window size range, expected QPS, read/write ratio, consistency requirements, and whether approximate QPS is acceptable. This determines the choice of data structures and trade-offs.

2. Design the key-value store core

Choose an appropriate storage engine (e.g., LSM-tree for write-heavy, B-tree for read-heavy) and discuss partitioning, replication, and durability. Explain how put and delete operations are handled.

3. Design the sliding window QPS tracker

Propose a time-bucketed ring buffer where each bucket stores a count of operations (or per-key counts) for a fixed interval. Use atomic counters for concurrent updates. For queries, sum over buckets within the window.

4. Analyze memory and performance trade-offs

Discuss how bucket granularity affects memory (number of buckets) and accuracy. Compare update cost (O(1) per operation) vs query cost (O(window/bucket_size)). For large windows, consider hierarchical buckets or approximate sketches.

5. Address scalability and edge cases

Explain how to handle high cardinality (e.g., per-key QPS), concurrency, and window resizing. Mention distributed aggregation if the store is sharded, and how to avoid hotspots.

Key Points to Mention

Time-bucketed ring buffer with atomic counters for O(1) updates and O(k) queries where k is number of buckets in window.
Trade-off between bucket size and memory/accuracy: smaller buckets give finer granularity but more memory and higher query cost.
For large windows, use hierarchical time buckets (e.g., 1s, 1m, 1h) or approximate data structures like count-min sketch to bound memory.
Concurrency control: use lock-free atomic operations or sharded counters to avoid contention on hot keys.
Distributed design: if the KV store is sharded, each shard maintains local QPS counters and queries aggregate across shards, possibly with a coordinator.
Window semantics: sliding window vs tumbling window, and how to handle out-of-order events or clock skew in distributed systems.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.