Do you find that unnecessarily adds latency for webhook event ingestion from the US? Seems like that would add a point of failure that makes me even more nervous here -- instead of a quick request to us-east-2, I have to send data across the pond.
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.
Doesn't matter the terms suggest the company is based in Delaware:
This agreement will be governed by the laws of the Delaware, USA. The courts of Delaware have exclusive jurisdiction to settle any dispute arising out of or in connection with this agreement
IANAL, though this is for disputes. Not for compliance with international laws which we can do anyway. The question is: can a US company with servers solely in Europe can comply with the European legislations. Based on my understanding the answer is yes, though I'll double check with the experts. :)
