Design a digital game store backend

Design the backend of an online store that sells digital games. Players browse a catalog, buy games with a wallet balance or a card, and own them afterwards in their library; they can also ask for refunds. The focus is the money path: modelling wallets and purchases so the books always balance, granting a game exactly once per purchase, refunds, idempotency, and recovering when a step fails partway or a request is retried.

Requirements

• Functional: browse the catalog and prices; top up a wallet; buy a game with the wallet or a card; see owned games; refund a purchase within a policy window.
• Functional: a purchase either completes fully (money taken, game granted, transaction recorded) or leaves no trace that matters to the player.
• Non-functional: no double charges and no free games under retries, timeouts and crashes; an audit trail for every change of money; high read traffic on the catalog, spikes on big releases.

Clarifying questions

• Wallet only, card only, or both? Is a card payment captured by an external provider?
• Can a player buy the same game twice, for example as a gift?
• What is the refund policy, and does a refund remove the game from the library?
• Multiple currencies or regional prices?
• What are peak purchase rates on a big release?

What a strong answer covers

• Services and data: catalog (cacheable), wallets, orders or purchases, entitlements (the library), payments; which ones need strong consistency.
• A ledger model for wallets: append-only entries with balanced debits and credits, balance derived or kept with the entries in one transaction, integer minor units.
• The purchase as a state machine (created, payment pending, paid, granted, refunded, failed) with an idempotency key from the client, so a retried request returns the same purchase.
• Wallet purchase in one database transaction: debit the wallet, create the entitlement with a unique key on (player, game, purchase), record the order.
• Card purchase across a boundary: authorize with the provider using its idempotency key, then grant; failures in between handled by a recovery job or saga that either completes the grant or voids the payment; provider webhooks applied idempotently.
• Refunds as new ledger entries, never edits, and revoking the entitlement.
• Reconciliation against the payment provider, alerts on mismatches, and handling a release-day spike (queueing purchases, caching the catalog).

Follow-ups

• The provider charged the card but your service crashed before granting the game. Walk through the recovery.
• Two purchases from the same wallet race and the balance covers only one.
• Add bundles and discounts that change price at a set time.
• A chargeback arrives a month later. What changes in the ledger and the library?