3 ms·
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 nervou
by ezekg 5y ago
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.
- tasn 5y agoYeah, 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.
- ezekg 5y agoThat'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.
- tasn 5y agoYeah, thanks a lot for the feedback! 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.