Case / 02 of 07
YumiGlow
One console. Multiple businesses. One answer for every balance.
Context
A multi-tenant administration platform behind several products, together with a standalone wallet engine responsible for the platform’s financial state.
The admin console changes its capabilities depending on the tenant. The wallet engine treats money as a system of records rather than a number on a screen.
System
What I built
- Multi-tenant administration
- Partner onboarding
- Bookings
- Customers
- Coupons and segments
- Content and media
- Ecommerce administration
- Wallet programs
- Double-entry ledger
- Holds
- Expiry
- Reconciliation
- Tenant-aware authorization
The hard part
A balance should be explainable.
The wallet engine uses append-only journal entries, spendable lots, FIFO allocation, holds with TTLs, idempotency records and reconciliation.
If the system says someone has ₹500, there needs to be a reason for that ₹500.
Engineering decisions
- 01
Append-only journal.
Balances are derived from double-entry records, never edited in place.
- 02
Integer minor units.
Amounts are stored as integers, so there is no floating-point drift.
- 03
Spendable lots with FIFO allocation.
Credits keep their own expiry and are spent oldest-first.
- 04
Holds with TTLs and idempotency records.
A retried request can’t apply twice, and unused holds expire.
- 05
Tenant-aware authorization.
The console’s capabilities follow the tenant, not the UI.
Shipped
- Multi-tenant console
- Standalone wallet engine
- Prometheus metrics
- Docker
Stack
- React
- Vite
- TypeScript
- NestJS
- PostgreSQL
- Turborepo
- Redis
- Docker
- Prometheus