more progress

content/how-we-cut-our-aws-costs-part-2/index.md

@@ -1,18 +1,40 @@
 ---
-title: 
-date: "2023-09-28"
+title: Using Multi-tenancy to cut our AWS costs by 50%
+date: "2023-10-01"
 description: "This tutorial wil guide you on how to add SuperTokens to a React and Express app deployed on Vercel"
 cover: "todo.png"
 category: "programming"
 author: "Joel Coutinho"
 ---
 
-This is part 2 in a two-part series where we go over how we cut down our AWS billing by 50%
+This is part 2 in a two-part series where we go over how we cut down our AWS billing by 50%.
 
 In this part we will go over SuperTokens Multi-tenancy feature and how it evolved our deployment cycle to cut our AWS billing by 50%.
 
-To recap what we discussed in our [last post](../how-we-cut-our-aws-costs/):
-- SuperTokens refined improved the deplyment cycle times by 
+As a recap here's what we discussed in our [last post](../how-we-cut-our-aws-costs/):
+- SuperTokens infrastructure and deployment cycle.
+- Improvements made to the SuperTokens deployment cycle to speed up production deployment times by 30%
+- How our infra costs were not sustainable and why it needed to change.
+
+## What is multi-tenancy?
+
+As mentioned in Part 1, "We saw multi-tenancy as an opportunity to optimize the utilization of our EC2 instances by consolidating our core instances. This would cut down our costs while also providing the expected performance"... But what does that mean? Lets break it down. Multi-tenancy is a feature, typically used by B2B SaaS companies to allow multiple organizations to sign up to their SaaS app, with the ability for each organization to have their own login methods or SSO configurations. Additionally, user pools can also be segmented. Heres how it helped us.
+
+## How we implemented SuperTokens Multi-tenancy 
+
+With multi-tenancy we re-architected the way we host and manage our users. Initially whenever a signed up and created an app with SuperTokens, it would trigger the following flow:
+
+[SuperTokens Old Deployment Process](./supertokens-deployment-process.png)
+
+In this process each development and production SuperTokens core ran in their own separate EC2 instances. With Multi-tenancy we now treat all SuperTokens customers as tenants. This means that we could now host multiple users on a single SuperTokens instance. Our deployment process now looks like this:
+
+[SuperTokens New Deployment Process](./supertokens-deployment-process-new.png.png)
+
+As you can see in the new deployment strategy, when a new user signs up, we now create a new tenant in a SuperTokens instance. These instances run in `T3 large` instances. In our testing, for development mode, up to 100 tenants can be run seamlessly on a single instance and for production mode, up to 50 tenants can be created on single instance.
+
+![SuperTokens infrastructure](./supertokens-infrastructure.png)
+
+
 
 - 100 apps per container. One example compared to 10 instances.
 

content/how-we-cut-our-aws-costs/index.md

@@ -46,7 +46,7 @@ So what prompted us to change our deployment process?
 ## Why we had to change our deployment process
 The past year has been quite a ride for SuperTokens. We released a host of new features and saw a big uptick in users. But, as our user numbers climbed, so did our infrastructure costs. With our AWS credits running out soon, we knew we had to do something to cut our expenses.
 
-With the release of our new multi-tenancy feature  we saw the opportunity to consolidate core instances to optimize the utilization of our EC2 instances to cut down our costs while also providing the expected performance. 
+With the release of our new multi-tenancy feature we saw it as an opportunity to optimize the utilization of our EC2 instances by consolidating our core instances. This would cut down our costs while also providing the expected performance.
 
 In part 2 we will go over the changes we made to achieve this.