System Design Questions Asked at Chargebee

• ·Create, upgrade/downgrade, and cancel a subscription
• ·Prorated billing when a plan changes mid-cycle
• ·Recurring invoice generation must be idempotent (never double-charge)
• ·Cancellation can be immediate or 'at period end'

1. 1. Model subscription lifecycle as an explicit state machine — trialing → active → past_due → canceled. Every transition is an event, not a free-form field update.
2. 2. Proration formula: prorated_amount = (days_remaining_in_cycle / days_in_cycle) × (new_plan_price − old_plan_price), charged/credited immediately on plan change.
3. 3. Billing runs as an idempotent scheduled job: generate one invoice per (subscription_id, period) — enforce a unique constraint on that pair so retries never double-bill.
4. 4. Cancellation writes a cancel_at timestamp instead of deleting the row immediately if 'cancel at period end' is requested — a background job flips status to canceled at that time.
5. 5. Emit webhooks (subscription.created, invoice.paid, subscription.canceled) so downstream services (email, analytics) stay decoupled from the billing core.

• ·Limit requests per user/API key over a time window
• ·Must work correctly across multiple app servers (not just in-process)
• ·Should allow short bursts without being overly strict

1. 1. For the full breakdown of all 5 algorithms (token bucket, leaky bucket, fixed/sliding window) with Redis Lua implementation, see the dedicated deep-dive.
2. 2. For a Chargebee-style answer: default to Token Bucket in Redis — atomic INCR/EXPIRE or a Lua script keyed by user_id, since it allows controlled bursts (e.g. webhook retries) while capping sustained rate.

• ·Support multiple vehicle types, and let new types (Truck) be added without rewriting core logic
• ·1 car-sized spot can be split to hold 2 bikes
• ·No two vehicles can ever be assigned the same physical spot — even under concurrent requests

1. 1. Use polymorphism, not a switch statement: each Vehicle subclass reports the spot type(s) it can use. Adding Truck later means adding one class, not touching ParkingLot.
2. 2. Model a car spot as splittable into 2 bike sub-spots via composition (a Spot can have child slots), rather than hardcoding a '2 bikes = 1 car' rule in the allocator.
3. 3. Concurrency: wrap spot selection + status flip in a single DB transaction using SELECT ... FOR UPDATE (pessimistic row lock) on the candidate spot row, or an atomic conditional UPDATE (UPDATE spots SET status='OCCUPIED' WHERE id=? AND status='FREE') and check rows_affected == 1.
4. 4. At higher scale, shard free-spot lookup through Redis (a set of free spot IDs per size) and use an atomic SPOP so two requests can never pop the same spot.

• ·Many independent counters (per tenant, per document type) generating IDs concurrently
• ·A counter can reset on a schedule (yearly/monthly) without ID collisions across periods
• ·No two concurrent requests may ever receive the same number for the same sequence

1. 1. Store one row per (sequence_name, period) in a counters table. Getting the next ID = UPDATE counters SET value = value + 1 WHERE key = ? RETURNING value — a single atomic statement, no read-then-write race.
2. 2. Reset is 'free': the period is part of the row key, so Jan 2027 simply starts a brand-new row at 0 instead of needing a reset job to run at midnight on Dec 31.
3. 3. For very high throughput, front the DB with a Redis INCR per key (sub-millisecond, atomic) and periodically checkpoint the value to the DB for durability/audit.
4. 4. Format the human-facing ID lazily: INV-{year}-{counter:06d} — the counter itself stays a plain integer.

• ·Track people, vaccine doses administered, and dates
• ·Answer aggregate/reporting queries (dose counts, coverage %) efficiently
• ·Data must be consistent — a person's dose count can't be ambiguous

1. 1. Pick MySQL/relational, not NoSQL — the workload is join-heavy reporting (per-region coverage, dose-count histograms) and strong consistency matters for a health record; a document store buys nothing here and loses easy aggregation.
2. 2. Normalize: one row per dose in vaccination_record rather than 'dose1_date, dose2_date' columns on person — this scales to any number of doses (boosters) without a schema migration.
3. 3. Index on (person_id) for the per-person lookup and (vaccine_type, administered_on) for reporting queries.

SELECT person_id, COUNT(*) AS doses_taken
FROM vaccination_record
GROUP BY person_id
HAVING COUNT(*) = :n;   -- everyone with exactly n doses, n >= 0 handled via LEFT JOIN + COALESCE if n = 0

• ·Millions of users hit the same endpoint within minutes of results going live
• ·Read-heavy, near-zero writes at the moment of the spike
• ·Each user only cares about their own roll number's result

1. 1. Pre-generate the result payload for every roll number ahead of the announcement and push it into a CDN/edge cache (or a static object store like S3 behind CloudFront) — turn a dynamic DB read into a static file fetch.
2. 2. Cache-aside in Redis keyed by roll number as a fallback layer for anything not pre-warmed, with a long TTL since results don't change after publishing.
3. 3. Rate-limit per IP/roll-number at the edge (WAF/API gateway) to blunt retry storms from impatient refreshing.
4. 4. Queue-based load leveling for any write-side work (e.g. logging, analytics) so it never competes with the read path during the spike.
5. 5. Horizontally scale stateless app servers behind a load balancer with autoscaling triggered pre-emptively at the announced release time, not reactively.

• ·Never double-charge a customer due to a retried request
• ·Distinguish retryable failures (network/timeout) from non-retryable ones (card declined)
• ·Client and server must agree on the outcome of a request even after a dropped connection

1. 1. Only retry on ambiguous/transient failures — network timeout, 5xx, connection reset. Never retry on a definitive business decline (insufficient funds, card expired) — retrying won't change the outcome.
2. 2. Require every payment request to carry a client-generated idempotency key. The server persists (idempotency_key → result) and returns the cached result for any duplicate key instead of re-running the charge — this is what actually 'stops' a client retrying a successful payment from double-charging.
3. 3. Use exponential backoff with jitter on the client for retryable errors, capped at a small number of attempts, so a flaky network doesn't turn into a retry storm on the payment provider.
4. 4. Reconcile asynchronously: even with idempotency keys, run a periodic job that checks payment-provider webhooks/status against your local records to catch cases where the client gave up before ever seeing the (successful) response.