Design alerting for application-to-exchange mappings
CitadelSoftware Engineer · OnsiteLast updated
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.
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. - Specify whether you want one-time alerts, repeated alerts, or alerts with cooldown.
- 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 walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.