One of the best problem to solve. Its kind of Balance Tracker but caveat is, One item can be part of multiple balance bucket. In such cases, you need atomicity across Balance Buckets. How would you solve it. ---- Problem Statement Design a system for a large e-commerce marketplace that evaluates every outgoing vendor payment against configurable spending rules, maintains running totals per rule, and enforces spending limits by holding payments when thresholds are breached. The marketplace pays thousands of vendors (logistics partners, suppliers, service providers) daily. Finance teams configure spending rules to cap how much can be paid out across various categories before requiring manual approval. Each payment must be checked against all applicable rules before it's released. A single payment may match multiple rules simultaneously. The system must accumulate the payment amount against ALL matched rules atomically. When a rule's accumulated total crosses a configured threshold, all subsequent payments matching that rule must be held for manual review. Functional Requirements 1. Rule Matching — Match each payment against rules with 6 optional wildcard dimensions (region, vendor_category, service_tier, vendor_id_list, expense_type_list, account_type), where null/empty means "match all." 2. Atomic Multi-Rule Accumulation — When a payment matches N rules, update all N running totals atomically (all-or-nothing). 3. Deduplication & Versioning — Guarantee exactly-once accumulation despite at-least-once delivery; handle versioned corrections by applying only the delta, including out-of-order arrival. 4. Threshold Enforcement — Hold all new payments matching a rule once its running total exceeds a configurable percentage of the approved limit; resume automatically when total drops below. 5. Reversals — Correctly decrement running totals when a version bump reduces or zeros out a previously accumulated amount. Non-Functional Requirements 1. Throughput — 10,000 payments/second peak; a single broad rule may see 5,000 writes/second. 2. Latency — p99 < 50ms for the hot path (match + dedup + accumulate); threshold decision adds < 5ms for 95% of rules. 3. Consistency — Accumulation is strongly consistent (no double-counting); threshold enforcement may be eventually consistent with bounded, justifiable staleness. 4. Availability — 99.95%; degrade gracefully (fail-open on enforcement, fail-safe on accumulation). 5. Cost Efficiency — Minimize per-payment I/O; not every payment should require reading all accumulator state to compute global sums. 6. Scalability — Support 100–10,000 rules; handle hot-key contention on popular rules without throttling.