Problem: Designing an Alerting System for Application-to-Exchange Mappings
You are tasked with building a service that processes an ordered stream of mapping events. Each event signifies a registration of an application to an exchange:
register(applicationId, exchangeId, timestamp)
It is important to note that a single application can be mapped to multiple exchanges.
Core Requirement
The primary goal is to raise an alert if an exchange becomes associated with an excessive number of applications, or experiences a surge in new associations.
What to Design
Your design should cover the following three areas:
- Define the Alerting Policy
- Propose a concrete policy for when an alert should be triggered. Examples include:
- Alert when the number of distinct applications mapped to a specific exchange exceeds a predefined threshold
T. - Alert when the number of new registrations for an exchange within a specified sliding window
Wexceeds a rate thresholdR.
- Alert when the number of distinct applications mapped to a specific exchange exceeds a predefined threshold
- Specify the desired alert behavior: whether alerts should be one-time, repeated, or include a cooldown period.
- Propose a concrete policy for when an alert should be triggered. Examples include:
- Implement the Detection Logic
- Detail the data structures and algorithms required to efficiently support your chosen alerting policy.
- Be prepared to discuss how to implement this efficiently, especially considering common techniques like a sliding window.
- Distributed / Parallel Considerations
- Assume that incoming events will be processed in parallel across multiple worker nodes.
- Describe how your system will maintain the correctness of alert decisions, even when events might be partitioned across workers, arrive slightly out of order, or be duplicated.
AI interview prep
Core dilemma
Balancing near-real-time, accurate stateful computations (e.g., counts, rates) for many entities (exchanges) against high-throughput, distributed, and potentially unreliable event streams.
3 tradeoffs and 3 stress tests locked
Interview prep
Unlock the interviewer X-Ray rubric, tradeoff matrix, stress tests, clarifying questions, and key concepts.
Problem: Designing an Alerting System for Application-to-Exchange Mappings
You are tasked with building a service that processes an ordered stream of mapping events. Each event signifies a registration of an application to an exchange:
register(applicationId, exchangeId, timestamp)
It is important to note that a single application can be mapped to multiple exchanges.
Core Requirement
The primary goal is to raise an alert if an exchange becomes associated with an excessive number of applications, or experiences a surge in new associations.
What to Design
Your design should cover the following three areas:
- Define the Alerting Policy
- Propose a concrete policy for when an alert should be triggered. Examples include:
- Alert when the number of distinct applications mapped to a specific exchange exceeds a predefined threshold
T. - Alert when the number of new registrations for an exchange within a specified sliding window
Wexceeds a rate thresholdR.
- Alert when the number of distinct applications mapped to a specific exchange exceeds a predefined threshold
- Specify the desired alert behavior: whether alerts should be one-time, repeated, or include a cooldown period.
- Propose a concrete policy for when an alert should be triggered. Examples include:
- Implement the Detection Logic
- Detail the data structures and algorithms required to efficiently support your chosen alerting policy.
- Be prepared to discuss how to implement this efficiently, especially considering common techniques like a sliding window.
- Distributed / Parallel Considerations
- Assume that incoming events will be processed in parallel across multiple worker nodes.
- Describe how your system will maintain the correctness of alert decisions, even when events might be partitioned across workers, arrive slightly out of order, or be duplicated.