Design the service that enforces spending and transfer limits on every transaction in real time. Before a payment is authorized, the service checks it against a stack of limits — per-transaction caps, rolling daily and monthly velocity limits, per-merchant-category ceilings — and returns allow or deny in milliseconds. The core tension is correctness under concurrency: two transactions racing on the same account must not both slip past a limit that only one should pass.

Operating context. This sits on the synchronous authorization hot path, so latency is unforgiving. Limits are consumed on authorization and must be released or settled later, and windows roll continuously (a trailing 24 hours, a calendar month). Limit policies vary by account tier and can be updated by risk operators. Assume 30000 authorization checks/sec at peak, tens of millions of accounts, and a hard rule that an account can never exceed a limit even under simultaneous requests.

Out of scope. The payment authorization decision itself beyond the limit verdict, fraud-model scoring, the ledger and settlement, and the risk-operator console beyond consuming its policy updates. Assume separate teams own authorization, fraud, ledger, and the policy tool.

What to produce. A high-level architecture covering: the low-latency check-and-consume path, the data model for limits and rolling-window counters, guaranteeing no over-limit under concurrent transactions on one account, reserve-then-settle/release semantics for pending authorizations, rolling-window accounting, propagating policy changes quickly, and scaling to tens of thousands of checks per second. Sketch the components and request flow; we will probe specifics in checkpoints.