InfoQ reported that 30+ Updates per Second per Account: Uber Scales Ledger Processing with Batching. Handling over 30 updates per second per account is more than just boasting about heavy workloads. It shows how Uber overcame a challenge common to all balance-tracking systems: systems handling "balances"—such as points, electronic money, wallets, inventory, and sales—cannot tolerate even a single yen or unit of discrepancy, yet concurrent updates concentrated on the same account frequently bottleneck due to row lock contention.
Meanwhile, on custom development front lines, incidents such as "points being granted twice," "cancellations crossing with purchases resulting in negative balances," and "ledger and sales totals not matching during monthly closings" continue unabated. From the perspective of supporting system development through custom projects, we view this not simply as "can we add and subtract balances?" but as an architectural challenge of "maintaining consistency without bottlenecks even under heavy concurrent updates, and delivering a system that remains fully auditable." Connecting with the massive data processing discussed in Redesigning Meta-Scale Data Ingestion Platforms in Custom Projects (GH Media), the processing reliability covered in Robust Backend Custom Development with Postgres / SQLite Workflows (GH Media), and the performance engineering explored in Backend Memory and Cost Optimization for Client Projects (GH Media), this article organizes our "Balance and Ledger Platform Design Support" into a custom development package.
Why balance systems differ from regular CRUD
| Dimension | Regular CRUD | Balance and ledger design |
|---|---|---|
| Correctness | Roughly matching is fine | Cannot drift by even one yen |
| Concurrent updates | Collisions are rare | Heavy collisions on the same account |
| Consistency | Overwriting is sufficient | Sequence of additions and subtractions alters outcomes |
| Reversals | Deleting restores state | Corrections recorded via reversing entries |
| Auditing | Nice to have | Full traceability of all transactions is mandatory |
| Deliverable | Working is enough | Zero drift, no bottlenecks, fully auditable |
In short, "being able to calculate balances" and "building ledgers that stay consistent, never bottleneck, and remain auditable" are two completely different things. In custom development as well, "designing append-only entries, idempotent ingestion, and concurrency-resilient update mechanisms, and delivering them complete with audit and closing workflows" has become a quality baseline. This allows us to guarantee a "discrepancy-free balance platform" as a deliverable.
Three pitfalls and design principles that break balance systems
Principle 1: Store as "append-only journal entries" rather than "overwriting current values"
Directly modifying balance columns easily leads to discrepancies under concurrency and system failures. In custom development, we structure data as an append-only ledger recording transactions row by row, where balances are aggregations, ensuring that everything can be recalculated and audited at any time.
Principle 2: Neutralize "duplicate executions" using idempotency keys
Retries and duplicate notifications result in double-crediting. In custom development, we implement idempotent ingestion using transaction IDs as unique keys, ensuring that results remain identical no matter how many times an operation is run.
Principle 3: Alleviate "row lock contention" via batching and partitioning
Concurrent updates targeting high-activity accounts stall on row locks. In custom development, we protect consistency while preserving throughput through batch aggregation of updates and account sharding (the core insight from Uber's case).
5 phases of "Balance and Ledger Platform Design Support" provided in custom development
Phase 1: Current state assessment (1–2 weeks)
- Incidence of balance discrepancies, double-grants, and closing mismatches
- Identifying concurrent update hotspots (high-activity accounts)
- Evaluating current transaction designs and idempotency
- Organizing audit and closing requirements
Phase 2: Ledger design (1–2 weeks)
- Designing append-only ledgers and snapshots
- Defining idempotency keys and consistency constraints
- Selecting contention-mitigation schemes (batching / sharding)
- Designing closing, reconciliation, and correction (reversing entry) workflows
Phase 3: Implementation (3–5 weeks)
- Implementing ledger tables and balance aggregation
- Idempotent transaction ingestion pipeline
- Batch aggregation / locking strategies for high-frequency updates
- Implementing audit logging and reconciliation jobs
Phase 4: Verification and migration (1–2 weeks)
- Consistency testing under concurrent updates and fault injection
- Migrating existing balance data and initial reconciliation
- Confirming throughput with load testing
Phase 5: Ongoing operations (continuous)
- Automated daily/monthly reconciliation and closing
- Balance discrepancy detection alerts
- Continuous hotspot monitoring and partitioning
Standard technology stack set for custom development
| Layer | Recommended approach | Alternative |
|---|---|---|
| Ledger | Append-only ledger + snapshots | Direct updates to balance columns (not recommended) |
| Idempotency | Unique constraints on transaction IDs | Custom ad-hoc duplicate checks |
| Contention mitigation | Batch aggregation / sharding | Simple row locks (bottlenecks) |
| Consistency | DB transactions + constraints | Left to application logic |
| Reconciliation | Automated reconciliation | Manual monthly reconciliation |
| Auditing | Immutable log of all transactions | Overwritten logs |
Which projects need this and which do not
| Projects requiring this | Low-priority projects |
|---|---|
| Handles points / wallets | Does not handle monetary amounts |
| Negative inventory/balances are strictly prohibited | No concept of inventory |
| Updates concentrate on the same account | Update frequency is very low |
| Auditing and closings are business requirements | Strict reconciliation not required |
| Double grants have occurred | No history of consistency incidents |
Six clauses to include in client contracts
| Clause | Details | What the client should verify |
|---|---|---|
| Target scope | Balances to convert to ledgers | Migrating existing balances |
| Consistency guarantees | Demarcation of responsibilities for discrepancy detection and reconciliation | Zero-tolerance premise for discrepancies |
| Performance | Throughput targets | Peak load requirements |
| Corrections | Reversing entry and cancellation policy | Audit compliance requirements |
| Handover | Design / Reconciliation runbooks | Maintenance framework |
| Ongoing maintenance | Closings / Monitoring | Operating costs |
Client-side ROI estimate (assuming points / wallets)
| Item | Direct balance updates | Ledger platform | Difference |
|---|---|---|---|
| Double-granting | Occurs each time / compensation required | Prevented by idempotency | Reduction in losses and refund handling |
| Balance discrepancies | Discovered during closings | Instantly detected via daily reconciliation | Avoidance of reputational damage |
| Bottlenecks | Stalls during peak periods | Absorbed through batching | Mitigation of lost business opportunities |
| Audit compliance | Tracked manually | Instantly tracked via logs | Reduction in operational response hours |
| Annual benefit | — | — | Reduction in grant losses + preservation of trust |
Even if substantial investment is required, it is fully justified solely by preventing losses from duplicate grants and avoiding brand damage caused by balance inconsistencies. For balances tied directly to money, the cost of a single incident far exceeds the cost of upfront design.
Five common pitfalls
Pitfall 1: Directly updating balance columns
Concurrency and failures will cause silent drift. Use an append-only ledger + aggregation.
Pitfall 2: Leaving retries non-idempotent
Duplicate notifications cause double grants. Enforce unique constraints on transaction IDs.
Pitfall 3: Handling high-activity accounts with simple row locks
System bottlenecks and stalls at peak. Relieve contention via batch aggregation / partitioning.
Pitfall 4: Handling cancellations via hard deletes
Audit trails are lost. Record corrections using reversing entries.
Pitfall 5: Relying on manual monthly reconciliation
Detection is delayed and damage spreads. Adopt daily automated reconciliation.
90-day action plan
| Week | Action |
|---|---|
| Week 1〜2 | Inventory of discrepancy causes and hotspots |
| Week 3〜4 | Designing append-only ledgers, idempotency, and contention mitigation |
| Week 5〜9 | Implementation + fault injection and load testing |
| Week 10〜11 | Balance migration + initial reconciliation |
| Week 12〜13 | Automating closings + launching discrepancy detection operations |
Conclusion — From "casual arithmetic" to "delivering systems that stay consistent, never bottleneck, and remain auditable"
Systems handling balances cannot tolerate even a single yen or unit of discrepancy, and they stall when concurrent updates concentrate. From the perspective of supporting system development through custom development, designing append-only journal entries, idempotent ingestion, and concurrency-resilient update methods, complete with audit and closing workflows prior to handover in our "Balance and Ledger Platform Design Support" serves as our new core offering that delivers discrepancy-free balance platforms as deliverables. For large-scale data ingestion platforms, read Redesigning Meta-Scale Data Ingestion Platforms in Custom Projects (GH Media), and for robust long-running processing, see Robust Backend Custom Development with Postgres / SQLite Workflows (GH Media).
If you are dealing with "points being granted twice," "balances not matching during closings," or "payments bottlenecking at peak times," please feel free to reach out via our contact form.
Sources
- 30+ Updates per Second per Account: Uber Scales Ledger Processing with Batching（InfoQ 2026-06-04）
- Redesigning Meta-Scale Data Ingestion Platforms in Custom Projects (GH Media)
- Robust Workflow Backend Services with Postgres / SQLite for Clients (GH Media)
- Backend Memory and Cost Optimization for Client Projects (GH Media)
