Design alerting for application-to-exchange mappings
Quick Overview
This question evaluates understanding of real-time stream processing, alerting policy design, and distributed state coordination for application-to-exchange mappings, testing competencies in scalability, correctness under partitioning and duplication, and efficient aggregation of high-volume event streams.
Citadel
Feb 11, 2026, 12:00 AM
Software Engineer
Onsite
System Design
17
0
Problem: Alerting design for application→exchange mappings
You are building a service that receives an ordered stream of mapping events:
-
register(applicationId, exchangeId, timestamp)
Each application can map to multiple exchanges.
Core requirement
If an exchange is associated with “too many” applications (or too many new associations) you must raise an alert.
What to design
-
Define when to alert
-
Pick a concrete policy, e.g.:
-
alert when the number of
distinct applications
mapped to an exchange exceeds a threshold
T, OR -
alert when the number of
new registrations
for an exchange within a sliding window
Wexceeds a rate thresholdR.
-
alert when the number of
distinct applications
mapped to an exchange exceeds a threshold
- Specify whether you want one-time alerts, repeated alerts, or alerts with cooldown .
-
Pick a concrete policy, e.g.:
-
Implement the detection logic
- Explain data structures/algorithms to support the policy efficiently.
- A common follow-up is to use a sliding window .
-
Distributed / parallel follow-up
- Assume events are processed in parallel across multiple workers.
- Describe how to keep alert decisions correct when events may be partitioned, arrive slightly out of order, or be duplicated.
Constraints (you may assume)
- High event rate (e.g., tens of thousands/sec).
- Many exchanges.
- You need near-real-time alerting (seconds).
Solution
Show