Design alerting for application-to-exchange mappings

## 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 1. **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 `W` exceeds a rate threshold `R`. - Specify whether you want **one-time** alerts, **repeated** alerts, or alerts with **cooldown**. 2. **Implement the detection logic** - Explain data structures/algorithms to support the policy efficiently. - A common follow-up is to use a **sliding window**. 3. **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).