## Prompt Design an API that records GPU-credit grants with activation and expiration times, records credit consumption at arbitrary timestamps, and answers the available balance at any timestamp. Events can arrive out of chronological order. Explain a correct replay model and then optimize repeated balance queries so they do not recompute from the beginning of history. ### Constraints & Assumptions - Every grant and consumption event has a unique event ID and event time. - A grant contributes only within its validity window. - Consumption may use only credit valid at the consumption timestamp and must follow a documented deterministic allocation policy. - Late events can change previously computed historical balances, so cached results need invalidation or versioning. ### Clarifying Questions to Ask - Are insufficient-consumption events rejected, partially applied, or retained as failures? - Should credits expiring soonest be consumed first? - How far back can late events arrive, and are historical answers expected to change immediately? ```hint Order the state transitions Define whether activation, consumption, and expiration at the same timestamp happen in that order or another documented order. ``` ```hint Checkpoint by event position A snapshot is useful only if it is bound to an event-log version and invalidated when a late event precedes it. ``` ### What a Strong Answer Covers - A precise event model and deterministic credit-consumption policy. - A replay algorithm that handles activation, consumption, and expiration in timestamp order. - Idempotency and stable ordering for events with the same timestamp. - Checkpoint, interval-index, or materialized-snapshot optimization with correct invalidation. - Tests for late grants, late consumption, overlapping windows, expiration boundaries, and insufficient balance. ### Follow-up Questions 1. How would you answer balances for many accounts without replaying inactive accounts? 2. How would you expose an audit explaining exactly which grants funded one consumption? 3. What storage design supports correction events without deleting history?