Katkat
Back

Design a digital game shop backend

DatabricksSoftware Engineer · Onsite
HardSoftware EngineerOnsiteSystem Design

Last updated

This question tests your ability to design a distributed, fault-tolerant transaction processing system for a digital storefront, focusing on data consistency and concurrency control.

Problem Statement

Design the backend architecture for a digital game shop (e.g., Steam or Epic Games Store). The platform supports game discovery, user wallets, and transactional purchases.

Core Requirements

  • Game Catalog: Support searching and viewing games with high read volume.
  • Wallet Management: Users maintain a digital balance. Purchases must deduct funds atomically.
  • Purchase Service: Enable users to buy games. A purchase must guarantee that a user is not charged twice for the same transaction, even in the event of network retries or service restarts.
  • Inventory Consistency: Ensure that a license for a game is granted exactly once per purchase.

Scale Assumptions

  • 10 million daily active users.
  • 5,000 transactions per second (TPS) during peak sales events.
  • High availability is required for the wallet and checkout services; read-heavy catalog service can tolerate eventual consistency.

Your Deliverables

  1. API Design: Define the interface for the Purchase service (including inputs to handle idempotency).
  2. Data Model: Propose a database schema for user wallets and transaction logs.
  3. Architecture: Describe the high-level services and storage engines. Explain how you prevent double-charging using distributed locking or idempotent keys.
  4. Failure Handling: Explain what happens if the game license delivery service fails after the payment is successfully processed.

Hints

Hint 1

Consider using an idempotency key generated by the client to track the status of a specific purchase request throughout the backend flow.

Hint 2

For the wallet service, compare the trade-offs between using a relational database with ACID transactions versus a distributed ledger approach to manage balances.

Hint 3

Think about using an asynchronous message queue (e.g., Kafka) to decouple payment processing from game license entitlement, ensuring durability via an 'outbox' pattern.

Follow-up questions

  • How would you handle a user requesting a refund for a game after they have already downloaded it?
  • If we introduce a 'flash sale' feature where a game is discounted for 60 seconds, how would you prevent the catalog service from becoming a bottleneck?
  • How would you implement a distributed 'lock' on a user's wallet balance to ensure that multiple concurrent purchases don't result in a negative balance?