This is particularly important in active-active configurations where a user request may be dynamically served from either region. When deploying across multiple regions for high availability we should stick with regions that are still within the same continent or within a reasonable distance from each other (e.g., eu-west-1 & eu-west-2, or us-east-1 & us-east-2). If all our users and clients are located in North America, we probably don’t want to have integration workloads located in Asia-Pacific, for example.
Any upstream latency will fall within the bounds of Anypoint Monitoring that allows us to easily monitor and alert on unexpected changes or poor response times.
That way you get the lowest possible latency between the client and the API. A point of best practice is that outward-facing APIs should reside as close to the clients as possible. We must remain mindful of latency and the impact on user experience. Where will your users be accessing our APIs from? Where do your client applications run? Where are your backends? Before you do this though, you should consider the rest of our architecture. So you’ve decided that we want to have multi-region availability to provide maximum fault tolerance. In the second part, we will discuss a more evolved approach that uses a dynamic content distribution system to route incoming traffic. We’ll then see how that would be constructed in practice using a simple DNS-based approach. In the first post of this two-part series, we’ll look at building a highly-available Runtime Fabric instance and how that is enhanced with a multi-region approach.
0 kommentar(er)
