6 Comments
User's avatar
Charles Fonseca's avatar

“Dynamic Routing: During this window, all read requests from that user are dynamically routed to the Primary database instead of a replica.”

I wonder how is that managed, it creates a strong coupling between the request, the database connection and the user performing an action.

Jay Vercellone's avatar

One approach is to store a "last write" timestamp in the user's session and use that in the next request to figure it out. This works fine in the browser, but for something like a REST API it's not simple, and so you have to instead infer the routing based on the HTTP method for example.

TRADE CRAFTERS's avatar

What’s interesting is how every solution here creates a new kind of fragility. You solve for speed, and now you’re managing consistency. You solve for scale, and now you’re managing truth across layers.

At a certain point the system isn’t just storing data, it’s constantly negotiating what the “latest version of reality” actually is. And the more layers you add, the more that reality depends on everything working together at once.

That’s the quiet tradeoff with scale. It gets stronger and more delicate at the same time.

cch's avatar

Maybe it is just me but I found the idea of "Dynamic Routing" is very weird thing to do.

Oleg Kuralenko's avatar

Surprised they installed replicas first and only then started thinking about caching

Eduardo Cucharro's avatar

Great post, thanks! But I have a question. They used debezium as a bridge connecting between postgres logs and valkey directly?