A Pods Architecture To Allow Shopify To Scale

In 2015, it was no longer possible to continue buying a larger database server for Shopify. We finally had no choice but to shard the database, which allowed us to horizontally scale our databases and continue our growth. However, what we gained in performance and scalability we lost in resilience. Throughout the Shopify codebase was code like this: Sharding.with_each_shard do some_action end If any of our shards went down, that entire action would be unavailable across the platform. We realized this would become a major problem as the number of shards continued to increase. In 2016 we sat down to reorganize Shopify’s runtime architecture.

Xavier Denis
4 min readbeginner
--
View Original

Overview

The article discusses Shopify's transition to a Pods architecture to enhance scalability and resilience after facing limitations with database sharding. It details the design of isolated pods that allow for independent operation and disaster recovery, ensuring that failures in one pod do not affect the entire platform.

What You'll Learn

1

How to implement a Pods architecture for improved scalability

2

Why isolating data stores enhances resilience in distributed systems

3

How to use a load balancer for routing requests to specific pods

Prerequisites & Requirements

  • Understanding of database sharding and distributed systems
  • Familiarity with load balancers and disaster recovery strategies(optional)

Key Questions Answered

How does Shopify's Pods architecture improve scalability?
Shopify's Pods architecture allows for horizontal scalability by isolating each pod with its own datastore, enabling independent operation. This design prevents failures in one pod from affecting others, allowing for seamless scaling as more pods can be added without interference.
What is the role of the Sorting Hat in request handling?
The Sorting Hat is a software component in Shopify's load balancers that matches incoming requests to the appropriate pod based on predefined rules. It adds a header to each request, allowing application servers to connect to the correct datastore and ensuring that only one pod is queried at a time.
What disaster recovery measures are in place for Pods?
Each pod is assigned a pair of data centers, with one acting as the active site and the other as a recovery site. This setup allows for quick recovery in case of a data center failure, and the Pod Mover tool facilitates moving a pod to its recovery site without dropping requests.

Technologies & Tools

Backend
Sorting Hat
Used for routing requests to the appropriate pod based on predefined rules.

Key Actionable Insights

1
Implementing a Pods architecture can significantly enhance your system's resilience and scalability.
By isolating components, you can prevent failures from cascading through your entire platform, allowing for more manageable growth and maintenance.
2
Utilizing a load balancer like Sorting Hat can streamline request routing in distributed systems.
This ensures that requests are efficiently directed to the correct pod, optimizing performance and reducing the risk of downtime.
3
Establishing a robust disaster recovery plan at the pod level is crucial for maintaining service availability.
By preparing for data center failures with dedicated recovery sites, you can ensure that your application remains operational even during unexpected outages.

Common Pitfalls

1
Failing to isolate pods can lead to platform-wide outages during shard failures.
Without proper isolation, a single point of failure can affect multiple shops, highlighting the importance of designing for resilience.

Related Concepts

Database Sharding
Disaster Recovery
Load Balancing