# Design a Payment-Count Dashboard That Scales with Readers and Updates Design a service that displays the total number of payments made on an administrative dashboard. Begin with one executive user and a low update rate, then evolve the design as both the number of dashboard users and the payment update rate grow. For the base problem, count each distinct payment record once and expose one all-time total. Do not add status filtering, time-range filtering, or grouped dimensions unless the interviewer explicitly requests them. Define how quickly a newly recorded payment should appear and whether the displayed total must be exact. ### Constraints & Assumptions - The payment system is the source of truth; the dashboard must not create or modify payments. - Payment-created events can be delivered more than once or out of order. - Historical recounts and reconciliation must remain possible. - Do not assume a particular throughput or freshness target without first eliciting it. ### Clarifying Questions to Ask - Is one all-time total sufficient for the base design? - How stale may the displayed number be? - What uniquely identifies one payment for retry and deduplication purposes? - How many dashboard users and payment updates must the system support now and later? ### What a Strong Answer Covers - A simple initial design appropriate for one reader - A clear evolution to event-driven materialized aggregates - Idempotency, reconciliation, and duplicate or delayed event handling - Read caching or push updates without losing a durable source of truth - Exact-versus-approximate and freshness-versus-cost trade-offs ### Follow-up Questions - How do you repair a counter that drifted? - What happens when an event is delivered twice? - How would the design change if time-range filtering were added later? - When would an approximate streaming count be acceptable?