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

SeniorPrefer not to say

Jun 2026

Summary

Meta system design round focused entirely on one meaty problem about tracking top customers by activity in near real time. The question had a lot of moving parts and I don't think I got through all of them cleanly.

Questions Asked (1)

Design a system that tracks the top N customers by cumulative activity (deposits, payments, and successful transfers only) in near real time, with efficient updates and queries. Cover data structures, API design, update/query complexity, late accept events, expired transfers, tie-breaking logic, dynamic N, and scaling to millions of customers.

System DesignAlgorithms & Data StructuresTechnical Trade-offs

Author's notes

This one spiraled fast.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then propose a streaming architecture with a real-time aggregation layer (e.g., Kafka + Flink) and a serving layer (e.g., Redis sorted set) for top-N queries. Discuss how to handle late events, expired transfers, dynamic N, and tie-breaking, and outline scaling strategies like sharding and approximate algorithms.

Pro tip: Emphasize idempotency and exactly-once processing for late events, and mention that using a sorted set with scores as cumulative activity allows O(log N) updates and O(log N + N) queries for top N. Also, consider using a probabilistic data structure like Count-Min Sketch for approximate top-N when exactness isn't critical.

1. Clarify Requirements and Constraints

Ask about expected throughput, latency requirements, definition of 'near real time', and whether approximate results are acceptable. Confirm that only deposits, payments, and successful transfers count, and that expired transfers should be excluded.

2. Design Data Model and Ingestion Pipeline

Propose a stream processing pipeline (e.g., Kafka + Flink) that ingests events, filters by type and status, and updates customer activity in real time. Use a state store for maintaining cumulative sums and handle late events with watermarks and allowed lateness.

3. Choose Data Structures for Top-N

Use a balanced BST or a sorted set (e.g., Redis ZSET) to maintain customers ordered by cumulative activity. For dynamic N, store all customers in the sorted set and query the top N on demand. Discuss tie-breaking (e.g., by customer ID or timestamp).

4. Handle Late and Expired Events

For late accept events, update the cumulative sum and adjust the sorted set. For expired transfers, if they were previously counted, subtract their amount and update the sorted set. Use event time processing and idempotent updates to avoid double counting.

5. Scale and Optimize

Shard customers across multiple nodes, use approximate algorithms (e.g., Count-Min Sketch) for memory efficiency, and cache top-N results. Discuss trade-offs between exactness and performance, and how to handle dynamic N efficiently.

Key Points to Mention

Use of stream processing frameworks (Kafka, Flink) for real-time aggregation with exactly-once semantics.
Data structure choice: sorted set (Redis ZSET) or balanced BST for O(log N) updates and O(log N + N) top-N queries.
Handling late events with watermarks and allowed lateness, and expired transfers by subtracting amounts.
Tie-breaking logic: when cumulative activities are equal, use customer ID or timestamp for deterministic ordering.
Dynamic N: store all customers in sorted set and query top N on demand; for very large N, consider pagination or caching.
Scaling to millions: sharding by customer ID, using approximate algorithms (Count-Min Sketch) for memory efficiency, and caching top-N results.

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