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

SeniorPrefer not to say

Jun 2026Remote

Summary

Coinbase system design round focused entirely on a real-time streaming problem around branch account openings. Pretty intense for a single question but they kept pushing on edge cases and distributed extensions the whole time.

Questions Asked (1)

Given a stream of account-opening events with branch ID, user ID, and timestamp, design a system to compute the top-K branches by number of openings for both all-time and a sliding window of the last T minutes. The system should support near real-time ingestion, queries at any time, and updates in O(log K) or better. Also address late or out-of-order events, memory constraints, and trade-offs between exact and approximate methods. Extend to a distributed setup and analyze complexity.

System DesignAlgorithms & Data StructuresTechnical Trade-offs

Author's notes

This was the whole interview, basically.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (exact vs approximate, latency, memory, distributed scale) and then propose a two-tier architecture: a fast in-memory layer for sliding window using bucketed time slots and a persistent layer for all-time counts. Use a min-heap or order-statistic tree for top-K with O(log K) updates, and discuss handling late events via watermarks or allowed lateness. Finally, extend to distributed setup with sharding by branch and merging results, analyzing trade-offs.

Pro tip: Emphasize the trade-off between exactness and scalability: for Coinbase-scale, approximate methods like Count-Min Sketch with a heap often suffice, but be ready to discuss how to achieve exact counts if needed. Also, mention that late events can be handled by maintaining a small buffer and reprocessing, but this adds complexity.

1. Clarify Requirements and Constraints

Ask about expected event rate, number of branches, T (window size), K, acceptable latency, and whether exact counts are required. Determine if events can be late and by how much.

2. Design Core Data Structures

For all-time: use a hash map from branch ID to count, and a min-heap of size K for top-K. For sliding window: use time-bucketed counters (e.g., per minute) and a sliding window aggregator; maintain a heap for top-K per window. Ensure updates are O(log K) by using a balanced BST or heap with lazy deletion.

3. Handle Late and Out-of-Order Events

Use event-time processing with watermarks to define when a window is complete. Allow a configurable lateness period; buffer late events and update counts retroactively, possibly recomputing affected top-K. Discuss trade-offs: longer lateness increases memory and complexity.

4. Address Memory and Approximate Methods

For high cardinality, exact counts may be infeasible. Propose approximate methods like Count-Min Sketch for frequency estimation and a heap for top-K, or Space-Saving algorithm. Discuss error bounds and memory savings.

5. Extend to Distributed Setup and Analyze Complexity

Shard by branch ID across nodes; each node maintains local top-K and counts. A coordinator merges results to get global top-K. For sliding window, use distributed time buckets and synchronize watermarks. Analyze time complexity: ingestion O(log K) per event, query O(K) to merge, and space O(B + K) per node.

Key Points to Mention

Use of min-heap or order-statistic tree for O(log K) top-K updates
Time-bucketed sliding window with watermarks for late events
Trade-offs between exact and approximate counting (e.g., Count-Min Sketch)
Memory optimization via sharding and approximate data structures
Distributed aggregation using local top-K and merge
Complexity analysis: ingestion O(log K), query O(K), space O(B + K)

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