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

SeniorPrefer not to say

Jul 2026

Summary

Dropbox system design round, one meaty question that took up the whole session. The problem sounds straightforward until you're actually in it trying to juggle concurrency, data structures, and distributed scaling all at once.

Questions Asked (1)

Design a key-value store that also tracks how many times each key has been accessed. It should support querying a key's hit count and returning the top-N most-accessed keys, both over all time and optionally over a sliding time window. Walk through your data structure choices, how you'd handle concurrency, and how the system scales horizontally.

System DesignAlgorithms & Data StructuresTechnical Trade-offs

Author's notes

I started with the obvious hashmap for O(1) gets and a max-heap for top-N, which felt fine until they pushed on the sliding window part.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (consistency, latency, scale, window semantics) and then propose a layered design: a core key-value store with an in-memory count-min sketch or exact counters for hit counts, and a time-bucketed sliding window structure. Discuss concurrency control (sharding, locks, CRDTs) and horizontal scaling via consistent hashing and replication.

Pro tip: Emphasize that exact top-N over sliding windows is expensive; propose approximate algorithms (e.g., count-min sketch + heap) and explain the trade-off between accuracy and resource usage, which shows you understand real-world constraints.

1. Clarify Requirements and Constraints

Ask about expected scale (keys, QPS), consistency needs, latency SLAs, and whether the sliding window is time-based or count-based. This ensures the design meets the actual use case.

2. Design Core Data Structures

For the key-value store, use a distributed hash table (e.g., consistent hashing). For hit counts, use a count-min sketch for approximate counts or exact counters with sharding. For top-N, maintain a min-heap of size N per shard, merged periodically.

3. Implement Sliding Window Tracking

Use time-bucketed counters (e.g., per-minute buckets) with a ring buffer to expire old buckets. For top-N over a window, aggregate buckets on demand or maintain a sliding window sketch.

4. Handle Concurrency and Consistency

Use per-key locks or atomic operations for updates. For distributed settings, use eventual consistency with CRDTs (e.g., G-Counter) or quorum-based replication. Discuss trade-offs between strong and eventual consistency.

5. Scale Horizontally

Shard data by key hash, replicate for fault tolerance, and use a coordinator to merge top-N results from shards. Consider caching hot keys and using a message queue for asynchronous count updates.

Key Points to Mention

Count-min sketch for approximate hit counts with bounded memory
Time-bucketed sliding window with ring buffer for efficient expiration
Consistent hashing for sharding and replication
Concurrency control: per-key locks, atomic counters, or CRDTs
Top-N aggregation using min-heaps and periodic merging
Trade-offs between exact vs approximate counts and latency vs consistency

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