Design game credit system with add/spend/refund APIs
Company: Ixl
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Technical Screen
You are designing a backend service to manage **virtual game credits** (in-game currency) for one or more video games.
The system should allow players to:
- **Add** credits to their account (e.g., after a purchase or a bonus).
- **Spend** credits (e.g., to buy in-game items).
- **Refund** a previous spend (e.g., when a purchase is cancelled or failed).
### Requirements
1. **Functional requirements**
- Each player has an account balance of credits.
- Support three core operations via APIs:
- `add` credits to a player's balance.
- `spend` credits, reducing the balance only if sufficient funds exist.
- `refund` a previous spend, restoring the corresponding amount.
- Track a history of credit-related operations for auditing and debugging.
- Prevent double-spending and inconsistent balances when multiple operations happen concurrently on the same account.
2. **What you need to design**
- A **database schema** (tables/entities, key fields, relationships) to store:
- User/account balances.
- Credit transactions (add, spend, refund), including references between them.
- Three **API endpoints** (you can assume REST over HTTP):
- `add` credits
- `spend` credits
- `refund` a previous transaction
- For each API, specify:
- HTTP method and URL.
- Request body format (fields, types, example JSON).
- Response body format (success and error cases, example JSON).
3. **Additional discussion topics**
Be prepared to answer **high-level design questions**, including:
- Which parts of your design could fail (e.g., database, network, service instances), and what happens in each failure case?
- How you ensure **consistency** of balances and transactions, especially under concurrency and partial failures.
- How you would prevent duplicate processing of the same request (e.g., when clients retry requests).
- How the design might evolve to handle high traffic (many players and many credit operations per second).
Assume a typical modern backend stack (e.g., a stateless application layer and a database). You do **not** need to write actual code, but you should provide clear data models, API definitions, and reasoning about reliability and consistency.
Quick Answer: This question evaluates a candidate's ability to design transactional backend services, covering API design, database schema for account balances and transaction history, concurrency control, idempotency, and fault tolerance; it is in the System Design category and targets the backend/database/API domain.