Game Backend Infrastructure: The 5-Layer Production Stack
A production game backend has five layers: edge/API, game services, durable data, cache/object storage, and workers/operations. See reference architectures for 1K, 100K, and 1M players, concrete technology choices, failure modes, and rough monthly cost.
Short answer: start with a stateless API and PostgreSQL. Add Redis only for measured hot paths, object storage for large immutable files, and workers for jobs that must not run inside a request. Keep the authoritative match process separate from the persistent backend. Kubernetes is an orchestration choice, not a prerequisite.
The five production layers
| Layer | Owns | Good default | Add complexity when |
|---|---|---|---|
| 1. Edge + API | TLS, authentication, validation, rate limits, routing | One stateless Go, C#, Rust, or Node service behind a load balancer | Latency, regional policy, or independent release cadence demands a split |
| 2. Game services | Player data, economy, leaderboards, matchmaking, server registry | Modules in the same deployable service | A bounded service needs independent ownership or scaling |
| 3. Durable data | Accounts, progression, inventory, purchases, audit history | PostgreSQL with backups and tested restores | Measured scale or access patterns justify another database |
| 4. Fast/blob data | Hot ranks, rate-limit counters, sessions, builds, config bundles | Redis for ephemeral hot state; object storage for large immutable objects | The database is proven to be the bottleneck |
| 5. Workers + operations | Season resets, stale-server cleanup, queues, exports, telemetry | Idempotent workers plus logs, metrics, traces, alerts, and audit events | Jobs need stronger isolation or guaranteed delivery |
Three concrete architectures
About 1K players: indie launch
- One API service with two instances for deploys and basic redundancy.
- One managed PostgreSQL database with automated backups.
- No Redis until profiling proves it useful; short-lived state can stay in process or in PostgreSQL.
- Object storage for server builds and config bundles.
- A simple VM or managed allocator for authoritative game servers.
Planning range: roughly $50-$400/month for the persistent platform, before authoritative game-server compute. Region, availability requirements, support, and traffic can dominate this range.
About 100K players: growing live game
- Stateless API instances autoscaled across at least two failure zones.
- Managed PostgreSQL with connection pooling, read replicas only where read traffic warrants them, and rehearsed recovery.
- Redis for leaderboards, matchmaking queues, rate limits, and carefully bounded cache entries.
- A durable job queue for notifications, exports, settlement, and retryable integrations.
- Regional game-server pools with warm capacity and a registry that expires missed heartbeats.
Planning range: roughly $1,000-$10,000/month for backend services, excluding the match fleet. Usage shape matters more than registered-account count.
About 1M players: large title
- Regional API ingress with explicit data residency and failover rules.
- Partitioning strategy based on player or title ownership, not premature microservices.
- Separate analytical ingestion from transactional writes so dashboards cannot harm gameplay.
- Capacity forecasting, load shedding, incident ownership, and game-day testing.
- Multiple game-server regions with placement based on latency, capacity, build, and game mode.
Planning range: tens of thousands of dollars per month and upward. At this scale, peak CCU, writes per active player, retained telemetry, and the realtime fleet are more useful budget inputs than MAU alone.
PostgreSQL vs DynamoDB
Choose PostgreSQL by default when the game has transactions, relational ownership, administrative queries, and evolving product questions. Inventory grants, purchases, bans, account links, and audit records benefit from constraints and transactions.
Consider DynamoDB or another key-value store when access patterns are known in advance, most operations address one partition key, horizontal scale is a present requirement, and the team understands hot partitions, secondary-index costs, and consistency tradeoffs. “NoSQL scales” is not enough reason to give up flexible queries.
Do you need Redis?
Use Redis for data that is hot, short-lived, reconstructable, or naturally ordered: rate-limit counters, matchmaking queues, presence, cached ranks, and expiring server heartbeats. Do not make it the only copy of purchased inventory or player progression. A cache outage should reduce performance, not erase truth.
Do you need Kubernetes?
No. A small backend on two VMs or a managed container platform is easier to operate. Kubernetes becomes attractive when the team already operates it, needs many independently deployed workloads, or uses an orchestrator such as Agones for a substantial game-server fleet. If nobody owns the cluster, Kubernetes adds a new production system without removing the old ones.
GameLift, Agones, or custom allocation?
| Option | Best when | Main tradeoff |
|---|---|---|
| AWS GameLift Servers | You want managed fleet placement and already use AWS | Provider coupling and a separate compute bill |
| Agones | You already operate Kubernetes and want an open game-server controller | You own the cluster, upgrades, capacity, and incidents |
| Custom allocator | The topology is small or unusual and a registry plus a few pools is enough | Every reliability feature becomes your responsibility |
Stateful vs stateless services
Keep API instances stateless so any healthy instance can serve any request. Put durable state in PostgreSQL, ephemeral coordination in Redis, and large immutable files in object storage. Dedicated game servers are intentionally stateful during a match; persist only checkpoints and outcomes needed after the process exits.
Server registry and matchmaking
A registry answers “which server processes are alive, on which build, in which region, with how many seats?” Servers register at boot and heartbeat with a short expiry. Matchmaking answers a different question: “which players should play together?” Once it forms a match, an allocator or registry chooses capacity and issues a short-lived join credential. Do not merge player matchmaking state with the lifetime of a process.
Observability you need before launch
- Request rate, latency, and errors by endpoint and status;
- database connection saturation, slow queries, locks, and replica lag;
- matchmaking queue time and failed allocations;
- active servers, missed heartbeats, crash rate, and build distribution;
- business invariants such as failed grants, duplicate settlement, and impossible balances;
- structured audit events for privileged changes.
Where teams fail
- Client authority: the client can grant currency, report hits, or write outcomes.
- No environment boundary: staging and production share credentials or data.
- Cache as truth: a Redis restart becomes permanent data loss.
- Unbounded retries: a dependency failure multiplies load until every layer falls over.
- One credential everywhere: players, game servers, and operators receive the same reach.
- No restore rehearsal: backups exist but cannot meet the recovery objective.
Build or buy?
Build when backend behavior is part of the game's differentiated design or when compliance and scale justify a platform team. Buy when the needs are standard—identity, player data, leaderboards, economy, server registry, live config, and matchmaking—and gameplay engineers would otherwise spend months recreating operations.
Crux implements this reference shape as a managed service: stateless API, PostgreSQL, Redis for bounded hot paths, object storage, workers, environment isolation, separate player/server credentials, and a server registry. The decision is not “architecture or BaaS”; a useful BaaS is an implementation of the architecture with less of it assigned to your team.
Continue by subsystem
Sources
Technical, pricing, and product claims were checked against these primary sources on the verification date above.