Traffic pattern
Stateful sessions, launch and event peaks
- A session lives on one server
- Matchmaking decides placement
- Concurrent rooms as the main measure
Solution scenario
A reference architecture for game servers and session load
When a player joins a session, that session lives on a specific server. Placement belongs to the matchmaking service.
- Primary decision
- Who makes the session placement decision
- Deliberate omission
- No load balancer is used in this architecture
- Separate lane
- Asset downloads are planned apart from gameplay traffic
Overview
Why does a gaming workload depart from a stateless architecture?
The defining property of this scenario is that the session is stateful. When a player enters a room, the session lives in a specific server process and later packets reach that same process. Placement belongs to the matchmaking service. Session servers are planned as a grid from concurrent room count. Patches and content packages are downloaded from object storage, and that traffic is budgeted apart from gameplay. The room server is planned in Istanbul (tr-ist-01) or Ankara (tr-ank-01).
Typical workload profile
Sessions are sticky, downloads arrive in bursts
Gameplay traffic and download traffic do not share a measure. Game packets are small and continuous, while asset downloads cluster on launch and patch days. Session data stays in memory, so the storage footprint remains small. The profile therefore takes concurrent room count as the base measure of capacity.
Data volume
Small session data, large asset packages
- Session state in memory
- Patches and content in object storage
- Download traffic clusters at launch
Latency and compliance
Round-trip time as the single critical axis
- Round-trip time on gameplay traffic
- Throughput on download traffic
- Player data as a scenario requirement
Capacity is planned from concurrent room count. The room server is chosen between Istanbul (tr-ist-01) and Ankara (tr-ank-01).
Reference architecture
The grid above, the asset lane below
The diagram splits into two decks: a six-room session grid above and an asset distribution lane below. The matchmaking service places players into the grid, and the sixth room, opened at peak, is drawn dashed. There is no link between the decks, because the download path and the gameplay path must never wait on each other. The dashed stickiness arrow shows a player’s later packets returning to the same process.
PortvMind Cloud services used
Four services: entry, session, assets and downloads
Floating IP fixes the entry, Compute carries matchmaking and the room servers, Object Storage holds the asset packages, and Network Data Transfer makes the download budget visible. With a stateful session, placement belongs to the matchmaking service.
Floating IP
The public address the client connects to stays fixed while the process behind it changes.
Compute
The matchmaking service and the room servers come from the same service on separate profiles.
Object Storage
Patches and content packages are downloaded from here, not from the game server.
Network Data Transfer
Download traffic is tracked as a budget line separate from gameplay traffic.
Each service page links back to this scenario; the link is generated from the same list in both directions. All Services
Evaluation criteria
Placement, measure, lane and budget
The table asks who owns placement, which measure capacity is calculated with, whether asset downloads sit in a separate lane and whether launch traffic is budgeted. The answer in the first row is where this scenario parts ways with the other six: the decision sits in the application itself, not in a distribution layer.
| Criterion | Question asked | Answer in this scenario |
|---|---|---|
| Placement owner | Which component places a player onto a server? | The matchmaking service — because the session is stateful, the decision is not left to a load balancer. |
| Capacity measure | Is capacity calculated per node or per room? | Per concurrent room; the grid is grown against that measure. |
| Asset distribution | Are patches and content packages downloaded from the game server? | No — the asset lane is separate, so downloads do not affect gameplay latency. |
| Egress budget | Are launch downloads budgeted separately? | Yes — download traffic is tracked apart from gameplay; the volume is set by the studio’s own measurement. |
Player data is planned among the studio’s architecture requirements.
Related guides and documentation
Reading on the asset store and protection
Adapting object storage to asset distribution and planning backup are covered in the guides. Bucket setup and operational steps are explained in the documentation. Matchmaking logic belongs to the application.
Guides
- Object Storage Architecture: How It Differs from Block Storage
Object storage keeps data in buckets as independent objects containing the data, a unique key and metadata rather than filesystem blocks. Applications typically access these objects through an HTTP-based, S3-compatible API. Block storage presents a disk volume to a server, where the operating system runs a filesystem or database. The object model is evaluated for media, backups, archives and data lakes, while the block model suits operating-system disks, databases and workloads that need low-latency random reads and writes.
- What Is Cloud Backup? How to Plan Enterprise Backups
Cloud backup stores scheduled copies of your servers, volumes and application data. With PortvMind Cloud Backup you create, track and restore those copies from the panel. A snapshot is for a fast rollback; lasting protection comes from Backup.
Guides
- Object Storage and the S3 API
The published Discuss guide for buckets and file usage.
- How-To Guides
Practical community guides for GPU, VKE, networking, security and Terraform scenarios.
Other solution scenarios
- Public Sector
A single controlled entry, nested boundaries and retention of the document archive.
- Manufacturing and Industry
A one-way bridge between the plant and the cloud, and a peak-free continuous stream.
- AI and Data
The training window, checkpoint volume and inference path are planned separately.
Let us design the session placement and the asset lane together.
Share your concurrent-room target, your patch rhythm and your current matchmaking logic; in the architecture consultation we map the grid plan and the download budget together.