What is the Geode pattern?
The Geode pattern is used for delivering global traffic. It is a pattern for distributing your backend application into “geographical nodes”.
It aims to reduce latency and increase availability. This is achieved by replicating your backend application into “geodes”. Each geode is deployed to a separate region and works in isolation.
Why is it needed?
Distributing the frontend of a website is easy. Using a CDN like Cloudfront allows your static content to be served from over 450+ points of presence around the world.
However, distributing the compute and data layers of your application globally is a much trickier problem to solve.
The classic pattern has been to “bring your data to your compute”. This is simple to set up, but causes latency if your Sydney backend needs to load data from your centralised London database.
The geode pattern solves this by utilising data replication between regions. This allows your customer to fetch data from the region closest to them.
When to use the Geode pattern?
The geode pattern should be used if:
- You require extremely high availability and resilience
- You require extremely low latency requests for users in different regions
- You require the ability to survive a full region being wiped out
- You hate money and want to replicate your services into multiple regions
While the last point is tongue-in-cheek, it is important to realise that replicating your architecture will also replicate your costs.
Data Replication for Geode pattern?
AWS offer many database solutions. Perhaps the most commonly associated with global deployments is DynamoDB. DynamoDB is their managed NoSQL solution.
DynamoDB has support for Global Tables. Each replica table exists in a different Region, it then automatically replicates that data to all other replica tables in the global table.
This multi-active, multi-region replication is what allows us to utilise the Geode pattern effectively. Reads to other regions will be eventually consistent, while within the same region can achieve strong consistency.
What makes a good Geode?
This design pattern implicitly decouples everything, resulting in a highly distributed and decoupled architecture.
Geodes should:
- Be self-contained within the Geode. If London goes down, Sydney should continue to operate.
- Be loosely coupled via an edge network and replication backplane. Utilising services like Route53, Cloudfront and AWS Global Accelerator.
- Be deployed by a template using tools like Cloudformation or Cloudfront.
- Ideally leverage cloud native and consumption-based billing services like Lambda to reduce waste created by duplicate deployments.
- Utilise a robust deployment pipeline. Since a request could execute asynchronously in different geodes, it is important to ensure all geodes are kept up to date.
What are the downsides?
- Not all databases in AWS support cross-region data replication.
- The majority of projects can gain a lot of these benefits from Multi-AZ rather than Multi-Region.
- Works best for cloud native applications.
Summary
The Geode pattern aims to provide high availability and low latency requests for global traffic.
It is easy to misuse this pattern and create an over-engineered and over-priced beast of an infrastructure project. So only implement this pattern after you have ruled out a more traditional Multi-AZ setup.