10B
usage events a day, 200,000 customers
About 116,000 a second, 350,000 in a festive-sale peak hour. Lose one and you lose revenue; count one twice and you overcharge.
Count each event exactly once
Bad: Increment a usage row
Timeout after commit: the retry double counts. A crash loses the call.
Good: Log + message-ID key
Retries reuse the key, here the WhatsApp message ID, and get dropped.
One WhatsApp send arrives three times. Bill it once.
The stream remembers keys for 24 hours, so it drops the retry but recounts the 30-hour replay. The daily close counts it once.
Dashboards need speed, invoices need exactness. Two codebases drift; the screen said ₹9,800, the invoice ₹10,200.
The trick
One definition, two schedules. Live every minute, exact at D + 2 days, marked “final through 18 October”.
₹36K
past zero with 5-minute batch deduction
That’s a ₹100-a-second sender with a minute of lag. Pre-debited leases, spent in gateway memory, keep the wallet from ever going negative.
Some October usage arrives after October’s invoice is final.
Wait 48 hours, then freeze. Later usage is priced at October’s plan and billed as a new line next month, never an edit.
Same events, same plan, same rupees
- Immutable plan versions with an effective date
- Price by the version in force at event time
- Round once per line, in integer paise
- Stamp lines with plan and code versions
Remember
Key and archive every event. One definition counts it live and exactly; leases guard wallets; invoices freeze, then correct forward.