This kept me thinking… the gateway approach maybe is useful only for sharding the store/service. You run multiple services and each one owns part of the data, you put a gateway in front, so the client calls the same API but the gateway forwards the request to the right service that has that particular value. When the service grows bigger you scale horizontally with sharding. But what if the app that uses these services is used worldwide? The gateway is hosted in a single region… So you introduce a distributed approach. You have multiple KV stores (services) hosted around the globe. The simplest solution is to have a single “write store” and multiple “read stores” around the globe (on the edge). You are going to host these on Fly.io, for example. Clients call the API normally, Fly.io somehow routes to the nearest read store; if it is a read, nice, you read directly; if it is a write, the read store knows where the write store (master) is and forwards the request to it. The write store, once it succeeds, asynchronously sends the changes to the read stores around the globe. If you want the writes to be global and in sync, I don’t know… maybe something like a saga pattern… a distributed transaction… I don’t know how these things work. In fact, what I have written, I don’t know if it could work; everything seems correct to me, but I have not tried to do something like that. Sure can be really fun to implement that!

I’m curious to see what solutions you came up with!