A family plan shares 100 GB across five SIMs with each SIM capped at 30 GB. How does charging enforce both limits at once?

The arithmetic that makes this interesting

Five members capped at 30 GB each can consume 150 GB between them, against a pool of 100 GB. That oversubscription is not a modelling error, it is the entire commercial point of a shared allowance: the operator sells the flexibility that any member may use more than a fifth of the pool, on the statistical bet that not all of them will.

The consequence is that two limits bind under different circumstances, and both must be live. A single heavy member is stopped by their own 30 GB cap while 70 GB of pool sits unused. Five moderate members are stopped by the pool with every one of them still holding personal headroom. The second case is the one that generates the support call, because the customer sees a counter at 18 of 30 and no service, and the system has to be able to explain that.

Two counters, one atomic decision

Online charging for this plan is the same credit-control conversation as any other, with a different quota calculation behind it. When a member's session asks for units, the charging function computes the grant as the smallest of three numbers: what remains in the pool, what remains under that member's cap, and the grant size policy would hand out anyway.

member M3 requests data quota

  pool_remaining      = 100 GB - 92 GB committed - 3 GB reserved  =  5 GB
  member_remaining    =  30 GB - 18 GB committed - 1 GB reserved  = 11 GB
  policy_grant                                                    =  2 GB

  grant = min(5, 11, 2) = 2 GB

  one atomic transition, both counters or neither:
    pool.reserved   += 2      guarded on pool_remaining   >= 2
    member.reserved += 2      guarded on member_remaining >= 2

The word doing the work is atomic. Reserving from the pool and then from the member counter as two independent operations gives you a window in which the pool has been debited and the member reservation fails, so pool units are held against a session that was never granted anything. Nothing later reconciles that, because nobody is waiting for it, and the family loses allowance they paid for. The two decrements have to commit together or not at all.

Committed and reserved are also tracked separately on purpose. A reservation is not spend; it is spend that might happen, and it has to be released when the session ends under its grant or when the grant expires because the node holding it died. Collapse the two into one number and unused reservations become permanent loss.

The group is the serialisation point

The standard advice for prepaid charging is to partition by subscriber, because a subscriber's balance is the contended resource and their concurrent voice, data and messaging sessions must be serialised against it. A shared allowance moves that boundary outward. The pool is contended by five members whose sessions are established on different network nodes, possibly in different sites, and the sum of their outstanding reservations is what must never exceed the pool.

So the group becomes the partition key, and every member's charging traffic for that plan routes to the same partition. Two things follow that are worth volunteering. Traffic per partition is now the sum of a whole household rather than one person, which matters for a plan sold to a small business with forty SIMs on one pool — the tail of that distribution, not the average, sizes the partition. And a member cannot be charged in isolation for operational convenience: moving one member's sessions to a different instance to relieve load reintroduces exactly the race the partition was there to prevent.

The design that fails here, and it is a common first answer, is to keep five per-member counters and derive pool consumption by summing them at decision time. Under concurrency two sessions both read a sum showing 4 GB left and both grant 3 GB. The pool has to be a single object that is conditionally updated, not a query.

Late and out-of-order usage against a shared pool

Not all usage arrives through the online path. Records from the offline pipeline turn up late, duplicated and out of order, and against a shared allowance lateness changes an outcome that a single subscriber's allowance would not have noticed.

The reason is that consumption order determines who was throttled. If member two's usage from Tuesday arrives on Thursday, the pool was in fact exhausted on Tuesday, and members three and four were allowed through on quota they should not have received. Rate against a group-period aggregate that is recomputed from event times rather than incremented in arrival order, so the final position is deterministic and identical regardless of delivery sequence.

That leaves a genuine gap between what the recomputation says and what the network already delivered, and it is not closable by better engineering. Service already provided cannot be retracted. What you can do is decide the policy in advance and make it explicit: for a postpaid pool the overflow is simply charged at the out-of-bundle rate, which is why postpaid shared plans are far easier than prepaid ones. For a prepaid pool, the operator is choosing between a small permitted overspend and refusing service to members who appear to have credit, and that choice is commercial rather than architectural.

Membership changes mid-period

The question always arrives as a follow-up because it is where the model leaks. A SIM joining a group on day twenty of a thirty-day period cannot sensibly receive the full 100 GB of shared entitlement, and cannot sensibly receive nothing either. Whichever you choose, the rule must be stated in the catalogue rather than implied by the code, because it is the number a customer will compare against a competitor.

Departures are worse, because the leaver's consumption stays consumed. If a member who used 40 GB leaves on day twenty, the pool cannot rise back to 100 GB remaining for the four who stayed without giving away 40 GB of service already delivered, and the 40 GB cannot simply remain consumed against them for the rest of the period without four people paying for a fifth who is gone. Model membership as an effective-dated relationship between the member and the group, attribute every rated record to the membership interval that contained its event time, and the awkward cases become arithmetic instead of argument. The same discipline that makes tariffs effective-dated makes group membership survivable.

Where candidates lose this one

The answer that sounds complete and is not enforces the caps in the offline pipeline. Rating usage afterwards, discovering the pool went over, and applying a charge or a throttle on the next cycle satisfies the billing requirement and fails the product requirement, because what was sold was a limit. A limit that is discovered after the fact is a price, not a limit.

The other tell is describing the pool as a balance and stopping there. A balance is money and behaves like money; a shared allowance is an entitlement with a validity period, per-member sub-limits, a rollover policy, and a defined order of precedence against other allowances and against money. Rating has to know which of a subscriber's allowances is consumed first, and getting that order wrong charges a customer cash while an entitlement they own expires unused.