Design game credit system with add/spend/refund APIs

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.