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

SeniorPrefer not to say

Jun 2026

Summary

Databricks system design round where they handed me a bare interface skeleton and told me to build a key-value store with a QPS tracking API. The requirements clarification part was basically the whole interview, which I wasn't expecting.

Questions Asked (1)

Design and implement a key-value store with put(key, value), get(key), and a QPS method that returns queries-per-second over a rolling time window. You're given only an interface skeleton to start.

System DesignAlgorithms & Data StructuresTechnical Trade-offs

Author's notes

The interface skeleton thing threw me.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements: expected QPS, time window size, concurrency needs, and whether the store is in-memory or persistent. Then design a simple in-memory key-value store using a hash map, and implement QPS tracking with a sliding window using a ring buffer or deque of timestamps. Discuss trade-offs between precision, memory, and performance, and consider thread-safety.

Pro tip: Mention that QPS should be measured over a rolling window, not a fixed window, to avoid burst artifacts at window boundaries. Also, consider using a lock-free or fine-grained locking approach for high concurrency.

1. Clarify Requirements

Ask about expected throughput, window size, concurrency, persistence, and whether QPS is global or per-key. This ensures you design the right solution.

2. Design Key-Value Store

Propose an in-memory hash map for O(1) put/get. Discuss thread-safety using locks or concurrent data structures if needed.

3. Implement QPS Tracking

Use a sliding window with a deque of timestamps or a ring buffer of counters per time bucket. Update on each operation and compute QPS by summing counts in the window.

4. Analyze Trade-offs

Compare sliding window vs. fixed window, memory vs. precision, and locking strategies. Discuss how to handle high QPS without performance degradation.

5. Test and Optimize

Outline unit tests for correctness and concurrency, and suggest optimizations like approximate counting or sampling for very high throughput.

Key Points to Mention

Sliding window vs. fixed window for QPS calculation and their trade-offs
Thread-safety mechanisms: mutex, read-write lock, or concurrent hash map
Memory overhead of storing timestamps and how to bound it
Time source: use monotonic clock to avoid system time changes
Handling of high cardinality keys and potential per-key QPS
Approximate algorithms (e.g., exponential decay) for memory-constrained scenarios

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