How to make sure a request is always delivered to a specific machine?

I’m building a turn-based strategy game using Flutter for the client and Serverpod for the backend, with Firebase for user/session management. The game flow is roughly:

  1. Players join a session (2 players per session).

  2. Each session runs on a single backend instance to simplify state management and reduce latency.

  3. Players send moves/actions from Flutter → Serverpod → Fly.io instance.

  4. Spectators can join the session to observe live game state, but do not modify it.

  5. Game state is synchronized via the backend and optionally persisted in Firebase/PostgreSQL.

Currently, my Fly.io app is deployed to multiple regions. I want to ensure that both players and any spectators in a session always hit the exact same machine, not just any machine in the same region.

Any advice, examples, or recommended patterns for handling this in a multiplayer game context with spectators would be greatly appreciated.

Thanks!

Have you read Dynamic Request Routing with fly-replay · Fly Docs

1 Like

Yeah, if your machines know enough about where people should be, then a nice pattern is:

  • Your users hit any machine
  • If this is a new game, that machine creates it
  • If they’re joining a game, that machine issues a fly-replay to the machine hosting that game

And if your games are identified by URL, you can also cache that replay for future visitors.

1 Like

will check out, thanks!

How would I identify by url?

For example, if your games are at /games/game/abcd-efghij-klm and abcd-efghij-klm is the unique ID for the game, you can set fly-replay-cache: /games/game/* and then set fly-replay-cache-ttl-secs: 300. Then you’d set the normal fly-replay header you want, and for the next 5 minutes the proxy will continue to send requests according to that fly-replay header.

There some documentation explaining this feature here: Dynamic Request Routing with fly-replay · Fly Docs

1 Like

Hi!

I’ve checked out the docs, and I wanted to ask about the
”fly-force-instance-id: 90801679a10038”

header. What’s the difference between this and fly replay? is this sent from the client?

Thanks,

> is this sent from the client?

Exactly.

For fly-force-instance-id, the client from the Internet sets that header, and the proxy will send the request to that specific instance. This is part of the client request headers.

For fly-replay, the client sends a request from the internet, it goes through the proxy to an instance of your application. Your application, responds to the request with the fly-replay header, and the proxy sees this response. This is part of the server response headers. Instead of returning the response to the client, it then sends the request according to your fly-replay header (different instance, region, app, etc), and that new instance responds. The proxy then returns this response to the client on the Internet.

When you use the cache headers in addition to this, it will skip the round-trip to your app while the replay is cached and behave as if it had received the initial fly-replay header.

2 Likes

Got it, thanks!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.