[gingerlime]

It's an interesting idea to assume GETs will do no writes, as opposed to POST/PUT/DELETE and route them via middleware, but as an app developer, you need to be very mindful of any updates I suppose... replication delay can also create some weird scenarios I imagine...

[mrkurt]

That's all solved. We catch readonly errors from Postgres and issue the replay. Preemptively sending a POST to the primary region is an optimization, it works fine without doing that!

Replication lag is handled too in the Ruby library we pin requests to the for a few seconds. In our Elixir library, we actually monitor the read replica directly and reroute writes until it's caught up.

[gingerlime]

I understand roughly what the gem does, but you still need to be aware of it with your app. For example, if every request updates some activity stat, or the last page the user was on (which happens with some apps), you instantly lose pretty much all the benefits, right?

What about redis / sidekiq btw? :)

[mrkurt]

Ah I see what you're saying! You're basically describing our experience trying to run Discourse. Weirdly, naive, less complicated Rails apps work better multi-region on Fly than mature grownup Rails apps.

We use sidekiq + Fly in a single region with the primary database, and then write to the Redis from other regions asynchronously. It's a good time in Ruby world, I think Ruby 3 will simplify a lot of the weird background work people do.

Ruby 3 will definitely help us solve the problem of gets that do writes for stats or history, since those things can be done async. You can do a little of it now just by spawning a thread and writing the the writable Postgres in the background.