← Databricks Interview Insights

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

Senior
Jun 2026

Summary

System design round at Databricks for a software engineering role. The whole thing centered on building a key-value store with rate query support, which sounds manageable until you get into the weeds of windowed aggregation and concurrency.

Questions Asked (1)

Q1

Design an in-memory key-value store that supports PUT and GET operations, plus a query function that returns the average number of PUT or GET operations per second over an arbitrary time window (e.g. average GETs per second over the last 10 minutes). Cover your choice of data structures, how you'd handle variable window sizes, accuracy vs memory trade-offs, and concurrency.

System DesignAlgorithms & Data StructuresTechnical Trade-offs
Author's notes

I went with per-second buckets in a circular array pretty quickly, which felt right, but then they asked about arbitrary window sizes and I stumbled.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (e.g., expected throughput, latency, window sizes, accuracy). Then propose a design using a hash map for storage and a time-bucketed counter approach for metrics, discussing trade-offs between accuracy and memory, and finally address concurrency with sharding or locks.

Pro tip: Mention that you would use a ring buffer of time buckets (e.g., per-second counters) to support arbitrary windows efficiently, and highlight that this is similar to how real systems like Redis or Prometheus handle sliding windows.

1. Clarify Requirements

Ask about expected read/write ratio, throughput, latency, window sizes, and accuracy needs. This guides data structure and concurrency choices.

2. Design Core Key-Value Store

Propose a concurrent hash map (e.g., sharded locks or lock-free) for PUT/GET. Discuss memory management and eviction policies if needed.

3. Design Metrics Collection

Use time-bucketed counters (e.g., per-second) in a ring buffer to track PUT/GET counts. For a window, sum relevant buckets and divide by window duration.

4. Handle Variable Windows and Trade-offs

Explain how to support arbitrary windows by adjusting bucket granularity. Discuss accuracy vs memory: finer buckets give better accuracy but use more memory.

5. Address Concurrency

Ensure thread-safe updates to counters using atomic operations or locks. Consider sharding counters to reduce contention.

Key Points to Mention

  • Use of concurrent hash map (e.g., Java ConcurrentHashMap or sharded locks) for the key-value store.
  • Time-bucketed counters (e.g., per-second) stored in a ring buffer for efficient sliding window queries.
  • Trade-off between bucket granularity and memory/accuracy: finer buckets improve accuracy but increase memory and overhead.
  • Handling arbitrary window sizes by summing buckets and dividing by window length; partial buckets can be interpolated for better accuracy.
  • Concurrency control: atomic counters, sharding, or read-write locks to minimize contention.
  • Potential use of approximate algorithms (e.g., exponential moving averages) if exact counts are not required.

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