Skip to main content

Growing pains

As our system becomes bigger with more requirements and more users, making the right tech choices is crucial. Currently, we are using a single Postgres database for everything, but once you start handling hundreds to thousands of requests per minute, you will very quickly realize that there are many bottlenecks in the system and the database itself can become a very big and costly one.

note

I used to work at a company where the main and only database was a MSSQL database that was costing the company $120.000 per month, and it was barely stable. Needless to say that the migration effort was painful but well worth it.

Currently​

Currently, if we were to create a diagram of our system, it would look like this:

This has been serviceable until now but as part of this expansion effort we will introduce 3 new pieces of tech in our system, indicative of a cloud-native distributed application.

The plan​

We are going to introduce 3 new technologies in our system:

  • A NoSQL document-based database
  • A distributed cache
  • An asynchronous messenger

Let's take a closer look as to why we will expand the system in that way.

The NoSQL document-based database​

NoSQL document-based databases are known for helping systems achieve incredible scale, but they do come with drawbacks. The biggest one being that, this level of great scaling can only be achieved by introducing some limitations in the form of immutability and guarantees.

Azure Cosmos DB is a great choice for a cloud-native NoSQL database that can help us achieve incredible scale. We will move part of our domain there.

The distributed cache​

Any distributed system needs a distributed cache because in-memory caches are simply not an option. When we are scaling an application horizontally, we are running tens of hundreds of versions of the same application code.

Redis is an excellent and battle tested choice for a distributed cache that is incredible fast and scalable.

Asynchronous messaging​

Some operations don't need to happen synchronously. From confirmation emails on signup, to data collection for further analysis and everything in between, message buses can be a great way to introduce resilient asynchronous processing in our applications. In our case we will introduce a message bus by using Azure Service Bus.

By the end of this workshop our system will look like this: