Design in-game payment wallet system evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
##### Question
Design a payment system for an online game that supports in-game currency transfers between accounts. Provide data models and APIs to enable:
1) querying any account’s total inflow and outflow over the past 24 hours, and
2) retrieving an hourly balance time series for the past 30 days for any account.
Quick Answer: Design in-game payment wallet system evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
System Design: In‑Game Currency Transfers and Analytics
Context
You are designing the in‑game currency subsystem for an online game. Players can transfer currency between accounts. Product and ops need:
Near real‑time analytics for inflow/outflow totals over the past 24 hours for any account.
An hourly balance time series for the past 30 days for any account.
Assume a single in‑game currency, high read volume, and strict prevention of double‑spending. All timestamps are UTC.
Requirements
Enable transfers of in‑game currency between accounts.
Provide APIs and data models to:
a) Query any account’s total inflow and outflow over the past 24 hours.
b) Retrieve an hourly balance time series for the past 30 days for any account.
Deliver data models, APIs, and any supporting components necessary to meet these requirements with low latency and correctness.
Clarifying Questions to Ask Guidance
Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.
What a Strong Answer Covers Guidance
A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.
Follow-up Questions Guidance
What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?