Geode

Deploying a collection of backend services into a set of geographical nodes, each of which can service any request for any client in any region 

When to use this pattern?  

• Implement a high-scale platform(like Cosmos DB) that has users distributed over a wide area and then set auto scaling of the front end.

• For any service that requires extreme availability and resilience characteristics .

When NOT to use this pattern?  

• Situations where there’s no geographical distribution required.  

• Situations where a legacy platform needs to be refortified.  

• Simple architectures and requirements, where geo-redundancy and geodistribution aren’t required. 

Implementation  

• DevOps  

• Autoscalling  

• A Front-end Service (Azure Front Door)  

• A Replicating data store (Cosmos DB)  

• Serverless technologies (where possible)  

• API Management isn’t required, but can be added to provide more robust API layer 

Considerations  

• Choose whether to process the data locally in each region(then use the Deployment stamp pattern), or to distribute aggregations in a single geode and replicate the result across the globe.  

• Geodes can work in tandem, using Azure Cosmos DB change feed and a real-time communication platform, like SingleR  

• This design pattern implicitly decouples everything, resulting in an ultra-highly distributed and decoupled architecture  

• Distributed deployments have a greater number of secrets and ingress points that require properly security measures.  

• Performance is affected by the number of geodes that are deployed and the specific App Service plan applied to the API technology in each region.  

• Determine the availability requirements for your data.  

• Azure offers a variety of Load Balancers that provide different functionalities for distribution of traffic.