Ep 7: Cell-based Architecture 101 - When?
Learn several use cases of Cell-based Architecture
In the last post, I described the concept of Cell-based Architecture. It consists of three components: Cell itself, Routing layer and Cell migration. Now, you’ve already understood the problems that Cell-based Architecture solves and the basic idea about it, but it still sounds like a toy world example. Therefore, I’d like to introduce several use cases where Cell-based Architecture is useful.
The series consists of 5 short posts:
When to use Cell-based Architecture? (this post)
How to implement Cell-based Architecture?
Use cases
B2B SaaS a.k.a. Cloud services
Recent days, B2B SaaS becomes a popular business model as it’s profitable and scalable, like AWS. B2B SaaS is typically provided with some form of multi-tenant applications so that the service provider can utilize the shared resources to gain more customers than the system allows if everyone runs 100% workloads at the same time i.e. overcommit.
User-based cell partitioning
In such multi-tenant architecture, your business would be capped somewhere if you only run one application. For example, if your application has some limitations (e.g. hard limit of a cloud service) and can host up to 1K users, your business can’t scale more than 1K users.
Instead, with Cell-based Architecture, you can horizontally scale your business by simply adding more cells e.g. 1K*N users if there are N cells. Because B2B SaaS customers typically don’t require any interactions between customers, they’re easily isolated to cells. Here is the examples of user-based cell partitioning:
In addition, if you want to handle single-tenant use case, it’s pretty easily done with user-based cell partitioning because single-tenant cells are just a special variant of multi-tenant cells that have only one customer. Everything else can be identical.
Resource-based cell partitioning
Also, Resource-based cell partitioning is common since B2B SaaS providers typically charge per resources e.g. DynamoDB tables or S3 objects. This allows one customer to own more tables than one cell can serve. Let’s see the example below:
E-Commerce
The next one is a B2C example - EC site. Except product reviews, cross-user interactions are not needed in most of the cases, like B2B SaaS. So, it’s easy to partition by user i.e. one cell host whole user experiences. But, how to handle inventory? We can’t store silo of inventory to each cell because one SKU might be ordered by two users against different cells’ inventory i.e. Split brain problem.
Then, microservice comes in. Cell doesn’t have to be end-to-end full stack. For example, Frontend microservice is split by user while Inventory service is split by resource e.g. SKU. Then, Frontend service cells talk with Inventory service through its Routing layer when accessing SKU.
Physical silo
The last example is a little bit unique. Sometime your business is tightly coupled with physical locations. For example, you want to run microservices to manage operations in warehouses you physically own. Or, your service provides regional or AZ isolated features. In these cases, cells partitioned by physical locations makes more sense and whole microservices are partitioned by the same cell boundaries and only communicate within the same cell. Therefore, Routing layer isn’t needed in front of Microservice 2 in the example below:
Summary
In this post, I showed several use cases where Cell-based Architecture is used. B2B SaaS is suitable because users/resources are typically independent. EC site can be partitioned by users on frontend but backend data e.g. inventory would be served by different microservice with different cell dimension. Lastly, cells can be tied with physical locations to isolate whole system stack per location.
What’s next?
So far, we’ve learned several Cell-based Architecture patterns at very high level design. In the last post of this series, I’d like to show more detailed examples so that you can see some actual working code to wrap up this 101 series.
Thank you for reading. If you’re interested in this series, please hit the “Like“ button and share this to any social media. I would be motivated more! Also, subscribe this magazine to receive the upcoming posts for this series!
Kudos! This series are really interesting to me even though I'm not working on architecture stuff as a professional. I cannot wait for reading your next article that is related to how to implement the architecture.