Forem: K.M Ahnaf Zamil

Building a multi-tenant PaaS application: Part 1 (Architecture & Initial Design)

K.M Ahnaf Zamil — Sat, 04 Oct 2025 11:00:02 +0000

TLDR: I’m building Stratus, a multi-tenant PaaS, to understand how platforms like Heroku handle orchestration and scaling. Part 1 covers the architecture, node scheduling, agent design, and deployment flow. Follow along for lessons learned from building distributed infrastructure from scratch.

There's a difference between using a tool and understanding how it works.

I've been deploying applications to Heroku, Railway, and similar platforms for years. They abstract away the infrastructure complexity - which is great for shipping products, but terrible for learning how distributed systems actually work.

I wanted to understand:

How does a platform decide which server should run your code?
How do multiple servers coordinate without stepping on each other?
What happens when things fail? How does the system recover?

You can read about these problems in books and blog posts. But for me, the only way to truly understand something is to build it.

That's why I'm building Stratus - a multi-tenant PaaS infrastructure that handles container orchestration across distributed nodes. It's not fully production-ready (yet), and that is not the real goal. The goal is to understand the foundational patterns that platforms like Heroku rely on.

Turns out, building even a simplified version teaches you more than a dozen textbooks.

This is Part 1 - covering the foundation of Stratus. I'll be writing more parts as the project progress.

What is Stratus?

Its a multi-tenant Platform-as-a-Service infrastructure I built to understand how platforms like Heroku work under the hood.

It handles code uploads and deployments, intelligently selects compute nodes based on resource availability, agent-based orchestration, fault-tolerant task distribution with health checks, etc.

At its current state, the project is optimized for batch jobs and worker tasks. HTTP ingress and external traffic routing is planned next.

High-Level Architecture

I tried to go for a K8s-like architecture for this project whilst keeping it as simple as possible.
There are four main components:

API Server (user-facing, accepts deployments)
Management Plane (The puppet master i.e. orchestration brain, schedules tasks and keeps track of compute nodes along with health checks)
Deployment/Compute Nodes (Virtualized or bare metal servers that run containers, each are a part of the Stratus cluster, managed by the Management Plane)
Node Agent (An agent software that runs on each Deployment Node in order to respond to health check requests, deploy and manage containers)

In a nutshell, the architecture follows a control plane/data plane pattern. The Management Plane makes decisions about where to run workloads. Deployment Nodes execute those decisions. Agents on each node handle communication and container lifecycle management.

The Deployment Flow (Step-by-Step)

The entire deployment flow starts with the user uploading the code as an entire folder, which gets stored as a ZIP file on MinIO/S3.

Step 1: User uploads code

API receives code upload
Creates deployment record
Sends gRPC deployment task to Management Plane

Step 2: Management Plane schedules the deployment

Queries available compute nodes
Evaluates resource availability (CPU, memory, existing containers)
Selects the least-burdened node
Sends task to that node's Agent

Here's a snippet of how the Management Plane selects the optimal node

def get_least_burdened_node():
    """
    Returns the node_id of the least burdened node based on CPU and memory.
    """
    if not _nodes:
        return None

    sorted_nodes = sorted(
        _nodes.items(), key=lambda item: (item[1]["cpu"], item[1]["mem"])
    )
    return sorted_nodes[0][0]

Step 3: Agent executes the deployment

Receives deployment task
Pulls user code from S3 and mounts it onto Docker container
Runs container with stratus_init.sh as entrypoint
Reports success/failure back to Management Plane

Step 4: Deployment is live

Container is running
Management Plane tracks it
User sees deployment status

Agent-Based Architecture

In order to register a worker machine as a part of the Stratus cluster and to run containers on it, I created Agent applications to run on each Deployment Node.

Initially, these are the problems I faced:

Management Plane needs to communicate with many compute nodes
Direct SSH or API calls don't scale well
Need resilient, asynchronous communication

And after implementing Agents:

Each compute node runs a persistent Agent
Agent registers with Management Plane on startup
Receives tasks, executes them, reports status
Like Kubernetes kubelet or Nomad agent
Responds to health check requests

I chose Golang for the Agent because it has low overhead and it's very good for this purpose due to its concurrency model.

A simplified example of how the Agent runs an application container

func RunDeploymentContainer(ctx context.Context, deploymentId string, deploymentFilesPath string) error {
    client, err := getAPIClient()
    if err != nil {
        return err
    }

    // Generate a logical container ID for internal tracking
    containerId := util.GenerateCryptoID()
    config := &container.Config{...}

    hostConfig := &container.HostConfig{...}

    // Create container with deterministic name
    resp, err := client.ContainerCreate(ctx, config, hostConfig, nil, nil, fmt.Sprintf("deploy-%s-%s", deploymentId, containerId))
    if err != nil {
        return err
    }

    // Start container
    if err := client.ContainerStart(ctx, resp.ID, container.StartOptions{}); err != nil {
        return err
    }
    return nil
}

Fault Tolerance & Health Checks

At the moment, I have not implemented a robust method to handle failures in the system.

Currently, the Management Plane sends gRPC requests to every Deployment Node and the Agent must respond with the system resources available (CPU and RAM).

The Management Plane keeps an internal state of each node and later on, decides to offload deployment tasks based on it.
In case a Node dies or becomes irresponsive, the failed health check will cause the Management Plane to not send any tasks to that Node.
Rather, it will keep sending health check request until the Node is responsive again. Once that happens, it will start receiving tasks as usual.

A simple yet effective approach for now.

Here's what I learned

When I first thought of building Stratus, I was somewhat clueless on where to start, because there's so many moving pieces and every one of them is required for the entire thing to function properly.

I'll have to admit, distributed state management isn't easy. Tracking which nodes have what containers requires careful design.

There's so many edge cases which need to be taken into consideration when running something of this scale. After all, anything can go wrong (and it will).
This has helped me to understand why Kubernetes is so complex - it handles every edge case I'm discovering.

Things like container rescheduling, dynamic routing (since the internal network is completely isolated) will require lots of planning and careful considerations.

And gVisor had made it a complete pain for me to access the containers through Docker's internal network, without tweaking the network isolation levels (or completely disabling it).

If there's something I'd do differently for this, I'd add observability from day 1. Developing this would have been so much easier if I had logs and metrics from the get go. That was probably one of the mistakes I made with this.

What's Next

Part 2 will cover the routing layer - how to expose containerized apps to the internet when they're running on internal networks across multiple nodes. P.S. it involves Consul, OpenResty, and sidecar proxying.

I'll also be working on implementing Horizontal scaling for this so it can run multiple containers application deployment. Stay tuned.

If you're interested in the code: Stratus GitHub

Have ideas, suggestions, or questions? Reply here or reach me at ahnaf@ahnafzamil.com - I’d love to hear from you!

Thank you for reading and have an amazing day!

OpenResty: The overpowered web server used by 40M websites (that people rarely talk about)

K.M Ahnaf Zamil — Wed, 13 Jul 2022 07:42:17 +0000

For the last three years, I have been working with server-side technologies, especially web servers to deploy my proxies and API gateways. I always thought Nginx was the best open-source web server you could get. Event-driven architecture, ability to load balance with upstreams, etc. They even claim to be a proxy server for email protocols such as POP3, and IMAP. But a lot of limitations and lack of modifiability had me looking for other options, and then I discovered the option I’ll never trade for another web server. I’m the type of person who yearns to spread the word about everything awesome.

Limitations of Nginx - What it didn’t allow me to do

Nginx had limitations that nobody usually complained about and that they used to solve in a lower layer of their infrastructure. Let’s say you want to check for authentication before sending the request to your app servers. With Nginx, there’s no way to run a middleware for this purpose. Rather, people tend to have an API gateway that receives all the requests from Nginx, and they run the authentication check there; after that, they pass the request to the app servers. This is slow, complex, and can even cost you more if you are using serverless infrastructure.

A few weeks ago, I was creating a web application where I needed to balance the traffic to Python Flask servers, which were registered on a Consul service mesh. Before even passing the traffic, I wanted my Nginx server to validate the authentication token so that my Python application wouldn’t have to do it. But that wasn’t possible with Nginx alone.

Nginx Plus tried to solve it in a way I didn’t like. The biggest thing it DIDN'T solve is the ability to modify the behavior of Nginx. It did offer njs, which is JavaScript you can run on Nginx; however, it doesn’t allow you to turn Nginx into a web application. Again, Nginx Plus is 2500$ per year, which is pretty expensive for small companies or independent developers. Plus, I’m a BIG fan of open-source software. Because of all that, Nginx Plus was a big no-no for me.

Behold, the almighty OpenResty!!!

First of all, let me get something straight. I am usually never fazed by technology. But OpenResty was probably one of the things that made me go “WHY DIDN’T I KNOW ABOUT THIS EARLIER?!?!?!?!” and there are many good reasons for that. When I first went to their website, I saw

OpenResty® is a dynamic web platform based on Nginx and
LuaJIT. It integrates the standard Nginx core, LuaJIT,
many carefully written Lua libraries, lots of high
quality 3rd-party Nginx modules, and most of their external > dependencies. It is designed to help developers easily
build scalable web applications, web services,
and dynamic web gateways.

I thought they were capping (basically, a brand new word for lying). A dynamic web platform that runs on Nginx, and can be modified using Lua? I don’t know about others, but I was convinced after reading this single line. It’s like you are getting all the features of Nginx, but also the ability to dynamically program it and make it work like your own thing. This means you get the performance of C, but write code with the ease of Lua. I was a bit concerned at first since I thought they were doing the same thing as Nginx Plus, but I was wrong.

You can use OpenResty for developing scalable web apps, web services, dynamic web gateways, APIs, and so much more! There’s no end to what you can do since you have been given the freedom to program its features.

OpenResty as a full-on web application? CAN YOU EVEN DO THAT?

OpenResty gives you the power to execute your application logic inside it. It’s made in such a way that you don’t even need an application server running and proxy requests to that! In terms of performance, you are getting the speed of C while executing application logic. You can also interface with databases such as MySQL, PostgreSQL, Redis, etc., directly in OpenResty and the community has plenty of modules/libraries for it.

Someone even made their blogging site only with OpenResty and Redis; they did not use any other backend application: https://github.com/torhve/LuaWeb. Unfortunately, they implied OpenResty to be a bunch of plugins; however, it’s a fully functional web platform on its own with its vast library of official and third-party modules.

OpenResty as a proxy and API-Gateway? Is that a thing?

Most people already have their application written in some other programming language such as Python, JavaScript, Java, etc., so they would want to use OpenResty as an API gateway instead of an application server. Using OpenResty, you can write code in Lua to make it work as an API gateway.

Some API gateways such as Spring Cloud Gateway, run server-side code (for authentication, or input formatting) and then proxy the requests. But with the JVM, the execution is less performant. Since OpenResty runs your code in Lua (which runs on C), you get blazing fast performance; which might not be visible for a small amount of traffic but will play a big effect when it comes to huge traffic.

Also, if you are talking about the Kong API Gateway, it’s built on top of OpenResty.

I used OpenResty for load balancing my Flask applications registered on a Consul service mesh. I sent DNS requests to the Consul server using Lua to fetch the application instances, and then proxied the requests to the application. Without OpenResty, I would have to use another Python application as an API gateway, which would be slower, and more agonizing. With a single Lua file, I turned OpenResty into a dynamic load balancer that uses Consul as its service discovery. Here’s the repository for my project: https://github.com/ahnaf-zamil/openresty-consul-proxy/

But who uses OpenResty?

I was a bit surprised when I first found out that Cloudflare had been supporting OpenResty since its early days and even uses it for a lot of their products. It is also worth mentioning that OpenResty was first sponsored by the Chinese e-commerce giant Taobao. According to NetCraft’s May 2022 web server survey, 40.7 million websites run on OpenResty.

NetCraft states this in its September 2016 survey,

“Switching from Nginx to OpenResty is not such a paradigm shift* as moving to, say, Apache or Microsoft IIS. The OpenResty web application platform is built around the standard Nginx core, which offers some familiarity, as well as allowing the use of third-party Nginx modules. One of the key additional features provided by OpenResty is the integration of the LuaJIT compiler and many Lua libraries – this gives scope for high performance web applications to be run completely within the bundled Nginx server, where developers can take advantage of non-blocking I/O.”*

Companies such as Kong, Shopify, GrubHub, Strava, AlgoExpert, Tumblr, etc, use OpenResty for powering their backends as well. The Kong API gateway itself is powered by OpenResty under the hood. It’s the 3rd most popular web server on the internet.

Even a lot of people who claim to be using Nginx are actually using the Lua module which was made by and for OpenResty. The Kubernetes Nginx ingress controller uses OpenResty under the hood through its Lua module: https://github.com/kubernetes/ingress-Nginx/blob/88e96decd95e7bd10e7de62b102284ff2bc82593/docs/how-it-works.md

One of the posts in Shopify’s Engineering blog states this,

“One of Shopify's secret weapons is our edge tier, which uses a combination of Nginx and OpenResty's Lua module. This module integrates into Nginx's event model allowing us to write Lua scripts which operate on requests and responses.”

Source: https://shopify.engineering/surviving-flashes-of-high-write-traffic-using-scriptable-load-balancers-part-i

I’m excited, how do I get started?

Firstly, you need to send $100 to a very fishy Bitcoin wallet to get a TOR link for the OpenResty binary on the dark web… just kidding. OpenResty is 100% open-source and FREE!!!!!! I mean, if it weren’t open-source, there wouldn’t be a point in having “Open” at the start of its name. I don’t know… I’m not the one who came up with the name :/

Anyways, I recommend you check out OpenResty’s website (https://openresty.org) first. OpenResty offers binary packages, but you can also compile from source code. I used the latter option (because I have an obsession with compiling stuff from scratch), and it didn’t take me long to do it, about 4-5 minutes.

Next, you can get started with OpenResty by reading the “Getting Started”(https://openresty.org/en/getting-started.html) page on their website. It doesn’t even scratch the surface, but you will get the idea of how simple it is to use.

If you want to know how you can make your own Lua module in OpenResty (that’s what you should do), then check out this video: Write Your Own Lua Modules in OpenResty/Nginx Applications.

Here’s the API reference for OpenResty: https://openresty-reference.readthedocs.io/en/latest/Lua_Nginx_API/

OpenResty is HEAVILY underrated

Compare the popularity of Nginx, Apache, or IIS with OpenResty. While OpenResty offers a lot more features and better performance in many cases, it’s not as popular as the servers that dominate the industry. I’m not sure why this is happening.

Is it because we tend to keep the most powerful weapons secret to have an advantage over our competitors? Or is it because the OpenResty company/community has been too humble and low-key to show off their amazing features?

I’m very curious about the psychology behind it, because if OpenResty was not popular, then people wouldn’t use it. Being used by 40.7 million sites and lots of big companies means that it is indeed popular. But I don’t understand why people barely talk about it. Whatever it may be, OpenResty is something I would look out for in the future as well. It has a LOT of potential, and I’ve just barely scratched the surface!

Conclusion

I made this post because I wanted OpenResty to gain more popularity, since it’s really an amazing piece of technology that is barely spoken of. It brings in a lot of things required in the current era of the web, where scalability and extensibility are key to having good and performant applications. I hope this post made you consider looking into OpenResty. Once you really get to understand the true power and beauty of this technology, I doubt you will move away from it. With that said, thank you for reading this long post and have a great day!

Service Registry: When should you use them and why?

K.M Ahnaf Zamil — Tue, 15 Feb 2022 07:13:58 +0000

Introduction

Recently I've been digging deep into microservices and distributed systems in order to get a better understanding of how bigger companies make applications and products that can scale almost infinitely. I've taken Netflix as a great example of microservice implementation in a product used by millions of people. They use microservices for literally EVERYTHING, and it's fully cloud-based (AWS).

But I see a lot of people (including me once) wondering how they keep track of their service instances when they autoscale. It's not like you have a set amount of service instances and you know their credentials (host and port). When you are autoscaling, you might have n amount of instances for a single service and not know their credentials.

For example, let's say you have 2 services: Service A and Service B. Service A depends on Service B for some kind of functionality. If you have one instance of Service B, you can just hardcode that instance's (Service B) credentials in Service A's configuration and use it. But what will you do when you have multiple instances of Service B and cant keep track of them?

How do you solve it?

That's where a Service Registry (also known as Service Discovery) comes into play. A Service Registry is basically a server itself, but it keeps track of all the other running service instances along with their credentials (host and port). The idea here is that whenever a new service instance starts, it will "register" itself on the registry by connecting to it and sending it's credentials as payload. Then it will just keep heartbeating (sending periodic packets) to let the registry know that it's "alive". If a service instance does not send a heartbeat for a long time, it will be considered as "dead" and removed from the registry.

Just in case you are confused, let me specify the abstractions here. The registry will have multiple "services". Here, a service can be some kind of application or server that is required in your application's architecture. Each "service" can have multiple "instances" because you might have to scale.

We got a registry, how do we access the instances?

We now know how we can register services, but how do we get an instance's credentials so that we can actually use it? One might say that we can just randomly select an instance from the registry. But that is not optimal since it's not 100% "random" and might return the same instance's credentials multiple times. The best option here would be to use some sort of load balancing algorithm. Most service registry systems come with a "round-robin" load balancing implementation which works best if you have servers with same specs/configuration. And when you are autoscaling, that would usually be the case. I can write a whole article on load balancing algorithms so I won't babble about it here.

Anyways, a load balancing algorithm will simply give you an instance's credentials by load-balancing all of the "alive" instances registered under that specific "service". Once you get the credentials of an instance, you can just use it in your application. BOOM!

I'm sold, but which service registry software should I use?

There are MANY good service registry software available, including one that I made (which is fairly new, but you can give it a try). I will list a few good ones here that I recommend for starters and production.

Conclusion

Well that is it for this post, I hope you enjoyed learning about Service Registries. It's been a while since I've written an article, so it might not be the best thing I've written. Regardless, I hope this new knowledge about Service Registries help you in the long run and make your backend easier to scale.

Happy Coding :D

My favorite stack for web applications, and why I use it

K.M Ahnaf Zamil — Wed, 18 Aug 2021 07:04:20 +0000

If you are a full stack developer, or just a web developer in general; you might have heard the term "Tech Stack" or just "Stack" in general. Basically, it is a set of technologies that you use to make your web applications. Pretty simple right?

There are many popular stacks which are used from small startups to big companies. These stacks include but not limited to:

MERN: MongoDB, Express, React, Node
MEAN: MongoDB, Express, Angular.js, Node
LAMP: Linux, Apache, MySQL, PHP etc.

When I make a web application, I want a tech stack that is lightweight, and easy to use/manage.

I call it the PERP stack (weird name)

P: Python
E: (E)nginx
R: React
P: PostgreSQL

Since I use Python and TypeScript as my primary languages, I use these for making my applications. On the backend, I use Python Flask (specifically) as my web framework. I use Ariadne with Flask as I like to use GraphQL instead of REST, whenever possible.

Flask is an unopinionated and lightweight web framework. It comes with the bare essentials, and there are tons of extensions which you can integrate to make your application, which is why I use it instead of a complete web framework like Django.

For the frontend, React is a must for me. I don't like any other frontend frameworks/libraries except React (just my own opinion). With React, I use URQL or Apollo client as the GraphQL client. Also, I forgot to mention that this will all be in TypeScript (because types are OP). UI-wise, I use Tailwind CSS, and Headless UI (Tailwind components for React, Vue, etc).

As my database, I leverage SQL over any other type of "main" database, specifically PostgreSQL. Of course, I would use something like Redis for user session and caching. The reason I use SQL is because it provides you with structured tables, so that the data always follows the same format and pattern. Relational functionality is also another pro to it. Foreign keys, joins, etc, are very useful SQL functionalities.

This is basically the set of technologies that I like to use for making my web application. Of course, there might be other better alternatives, but I just use it because I am more comfortable with using these. And it's not that bad. Let me know what tech stack you use for your web application, in the comments below. Hope you enjoyed this post :)

[Joke] Bad things about every programming language

K.M Ahnaf Zamil — Wed, 18 Aug 2021 06:24:28 +0000

This is just a sarcastic post where I rant about the bad sides of every programming language I have tried/used. Please don't be offended, as this just for entertainment purposes.

Let's get started:

Python: Slow as hell, no generics or types. I am not Harry Potter, Parseltongue is not for me. Spaces and tabs don't work together well. SNEK!!!

JavaScript: My life is undefined, every single tutorial on the internet is on JS.

TypeScript: Error: Property sanity of type Mind is undefined.

Java: I wish I had a widescreen monitor. JVM taking too much of my RAM. And the error tracebacks are bigger than my p- (rogramming skills)

C++/C: I wish pointers didn't exist, and type conversion was easier.

Rust: Lifetimes don't make sense. Car-go, car not fly.

Golang: No generics, error handling is disgusting. Why use zero values if nil exists? (nevermind, they got generics now.....)

C#: Microsoft™ Java. Also, pointers are useless here.

HTML: A very good programming language.

CSS: The only thing I can flex about in my life is a flexbox that I made when I was 12 years old.

I hope you enjoyed this post. Again, please don't take this offensively. A lot of the programming languages on this post are the ones I use, and they are pretty good. I just made the bad things sound funny :)

Web Application Scaling: For Dummies (like me)

K.M Ahnaf Zamil — Wed, 18 Aug 2021 05:48:47 +0000

Let's say you have created a blog website where you share your ideas and knowledge on coding. At the start, your website was small, and the traffic was low. A few weeks went by, and you see there is a lot of users now. They are requesting that you add forum system to the website (much like StackOverflow). You add that, and now everyone's happy. Seeing new features, there are more users now. Next week, a user contacts you via your email saying that they can't access your site.

Because the web server crashed....

When you log onto your VPS/server where your application is hosted, you see that the resource usages are peaking at 100%. Your single server/application instance cannot handle this insane amount of traffic coming to your website. So how do you ensure that your website is always up, and available?

By scaling!!

Tell me, what in the bananas is scaling?!?!?!?

Tldr, scaling is the process of making your application cope up with a huge amount of users. If one instance of your application cannot handle this much traffic, you spin up another server (cloud service providers like GCP, AWS, DigitalOcean, Azure, etc, make it easy and cheap) and host your application there.

That way, if one of your application server crashes, the other one can handle the traffic. Or, the huge traffic can be distributed to both of the servers, depending on which one is the least busy.

But here's a catch!

Since your application is hosted on two different servers (for the sake of scaling), each of the servers have a different IP address. But you have a single domain, so how will the user know which server to connect to?

We need to call upon the mighty Load Balancer!

What is a Load Balancer?!?!?!?

Well, since you have multiple servers for the web application, we need a server in the middle which will receive all the client requests, and distribute them to the application servers. So instead of assigning the domain to the web application servers, you assign the domain to the Load Balancer server, and all the users/clients will send the request to the Load Balancer. The Load Balancer will simply receive all the traffic, and send them to one of your application servers depending on which one is the least busy.

Most cloud service providers have their own Load Balancers which work very well. But if you are like me, and want to set up a Load Balancer form scratch, then you can use Nginx as your Load Balancer. Now don't get me started on Nginx, I can write a whole post about how great and useful Nginx is. Simply, it's not just a web server, you can use it as a reverse proxy, Load Balancer, TCP proxy, etc.

So now we have a simple but efficient Load Balancer which will distribute all of our traffic to the application servers. End of problem, right? Well, I wish I could tell you that. But there are still some things that need to be fixed.

First, the database.

How do you scale a freaking database?!?!?!?!?

Right now, a database instance is being hosted on each of your application servers. That would have been fine if you only had a single instance of the application, and the database is hosted on the same server as the application. But since we have multiple instances of the application now, it will be a problem. As the Load Balancer is sending the traffic to different servers at a time, each application server that receives the request will write to the database that is hosted on it's own server. So the data will be different for each server.

So how do we solve this?

Well, the best way to do it would be to have a centralized database. Now if your application is VERY big and works at a high scale, you might need to partition your database, or use some other database scaling pattern. But for now, just having a good old centralized database would work just fine. You need to spin up another VPS/server, and host your database software there. Or, you can use a managed database service like DynamoDB (AWS), RDS (AWS), SQL Database (Azure), etc, which you don't need to worry about scaling as the cloud provider will scale it for you.

Now, just make the application servers connect to that database. This way, the application state/data would be the same across every single instance since they are all using the same database server.

So we have a centralized database now, and all users are happily using your application. But suddenly, your blog started to pop off. People liked the content you were making, and they are so many users visiting your page that your database started to crash, and your reads per second rates are VERY high.

How do we solve this??

Let us implement a caching mechanism!

Bro, what is caching now?!?!?

Caching is a very simple concept, yet it is very useful. Whenever someone visits your website/blog, it is making a request to the database for the post. So if many users visit your blog, the number of database read requests is high. So instead of making a database request for every time someone visits a page, we can use a caching mechanism (or caching layer) that will simply cache your posts in memory, for some time. That way, instead of making a request to the database every time someone visits your blog, the request can be made to the cache, and that cache will return the data that is stored in the memory.

The caching layer (or simply, the "cache") can update itself every few minutes so that the data is not stale. Since it is a blog website, you won't be writing posts every 5 minutes, jeez. So the cache can just fetch the updated data from the database every 15 or so minutes, and store it in memory. That way, whenever a user visits your blog, it will fetch the data from the cache instead of the database; reducing the number of database read requests.

Conclusion

So now we know how we can scale a basic web application. This are just very simple scaling patterns, and bigger applications might need more advanced procedures to ensure maximum performance and uptime. Also, this is my first ever tech blog post, so please ignore any grammatical/spelling mistakes. That's all for this post, hope you found it helpful :)

The best type of application is the application that scales well - Dev Tzu, Art of Code