The Most Critical Decision in System Design: Stateless vs Stateful... Part ~ 1

Right now while you're watching this video, millions of data packets are flying between servers in the background. There is an invisible architecture that allows Netflix to remember exactly where you left off. Keeps your Amazon cart full for days. Or lets millions of people use Instagram simultaneously without the whole thing crashing. If you are designing a system, you will eventually reach that major crossroads: stateless vs stateful. Let's start with the most common one: stateless systems. The underlying logic is brutally simple. The server basically has the memory of a goldfish. It receives a request from you, processes it, and instantly forgets you. What you did in the past or who you are means absolutely nothing to the server. So why is this a good thing? The answer is just one word: scalability. Let's say your app suddenly goes viral and millions of people start logging in. Your server is on the verge of crashing. If your system is stateless, you can spin up 100 new servers right next to it. Since no server needs to remember user history, the incoming traffic is instantly distributed across these 100 servers. Scaling the system horizontally becomes child's play. Most of the REST APIs and serverless architectures we use today work exactly like this. To prove your identity, you have to pull your ID, like a JWT token, out of your pocket and show it to the server every single time because it will never remember you. But not everything can have a goldfish memory, right? If that were the case, your cart would empty every time you refresh the page on an e-commerce site. Or you'd have to log in from scratch with every single click. This is where stateful systems step in. Stateful systems remember your past interactions.