Yeah, this is less than optimal, and that's why we are working on adding zones. It just made sense to start with Europe while we are in just one (due to compliance). We also plan on having our API endpoints on many different zones so that for our customers API calls are immediate.
That's what I was thinking. Having ingress/egress processes in specific zones will definitely help here, while keeping your datastores in EU without any issues of data loss at the edge.
For example, ingress for receiving events in a US zone, those are asynchronously pushed to the EU datastore, and then egress for delivering the events are again in the US zone, transparently pulling data from the EU.
Not sure on your architecture, but just spit balling how you could keep data stored in the EU while temporarily "processing" that data in the US to keep latency low where it matters.
We are going to prioritize this task based on your feedback. It's definitely a concern. We don't even need to store the data in the EU if our users don't want/need it. We can even let them choose zones themselves for ingress - as in many (most?) cases, they would only be using one zone themselves.
