Katkat

Design alerting for application-to-exchange mappings

CitadelSoftware Engineer · Onsite

Last 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

  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.
  1. Implement the detection logic
  • Explain data structures/algorithms to support the policy efficiently.
  • A common follow-up is to use a sliding window.
  1. 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).