Cloud

Field note · 6 min

Shopify scales a monolith with pods

Isolated pods of shops, each with its own databases, behind one Rails codebase.

Shopify serves a very large number of online shops from one large application. It didn't scale that by splitting the application into many services. Instead, it split the data into isolated units called pods, each holding a set of shops on its own datastores, and kept one codebase serving all of them. Shopify's engineers described the design in 2018, and how they move shops between pods without downtime in 2021.

This note follows those two posts. Pods are a clean example of cell-based design: limiting how much of the platform any single failure can reach.

What they had

By 2015-2016, Shopify had already sharded its database by shop: each shop's data lived on one shard. Sharding solved capacity, but Xavier Denis's 2018 post explains what it cost:

If any of our shards went down, that entire action would be unavailable across the platform.

The problem is that the other datastores, and the code paths that touched several shards, were still shared. A request for one shop could depend on resources that served all shops. In the post's words, what was gained in performance and scalability was lost in resilience.