Putting an intermediate server between the client and the game server adds processing time at every hop, and that server becomes a single point of failure.
Why Client ↔ gateway ↔ game server architecture → Effect The intermediate server adds processing and queueing time, and when it’s overloaded everyone is affected → On screen Higher ping for everyone; if a gateway fails, every player routed through it disconnects
Primary owner Game team (Server development) · Also Infra team (Server infrastructure), Game team (Client development)
Game team action items
Server: make the gateway tier scale out to more machines, let a character carry on unchanged when it reconnects through another gateway after its gateway dies (session reconnection). Client: reconnect automatically when the gateway connection drops.
Infra team action items
Scale gateways horizontally (add machines), monitor CPU, connection count, and processing latency per gateway.
Ballpark numbers
Inside the same data center, each hop normally adds less than 1 ms. When the gateway is overloaded, that grows to tens to hundreds of ms.
On the graph
Rises with load · Gateway processing latency, gateway CPU and connection count
Where to look
Gateway CPU and connection count, Recv-Q on the gateway’s sockets (ss, netstat), and the latency difference before and after the gateway. For HTTP/gRPC calls through a service mesh, compare the Istio standard metric istio_request_duration_milliseconds split by sender (reporter=source) and receiver (reporter=destination)
Confirmed if
Game server processing time is unchanged but latency grows only across the gateway hop, and at the same time gateway CPU is saturated or Recv-Q builds up
Ruled out if
Paths that skip the gateway (direct connection, another gateway) are just as slow: points to the connection or the game server
Check with
Infra tools (no game code needed)
Learn more
With a service mesh such as Istio, the sidecar proxy (Envoy) running next to each server adds one more hop. A request between services passes through the sender’s sidecar and then the receiver’s sidecar, and every feature you add to the proxy, such as log and metric collection, adds processing and queueing time.
Performance and ScalabilityIstio In sidecar mode, a request passes through the sender’s sidecar proxy and then the receiver’s; every added feature lengthens the processing path inside the proxy, and telemetry collection adds queueing time to the next request
What is EnvoyEnvoy Envoy is a separate process running alongside every application server, and the app sends and receives through Envoy on localhost
Istio Standard MetricsIstio istio_request_duration_milliseconds (distribution of HTTP/gRPC request duration); the reporter label separates the sending (source) and receiving (destination) proxy