🔁 Stateless Applications

📌 Overview

In cloud design, we strive for Statelessness to enable infinite horizontal scaling.

1. What is Stateless?

A Stateless Application does not save client data (session state, like "Cart Items" or "User Login Status") on the web server itself.

• Every HTTP request happens in isolation.
• The server doesn't "remember" the previous request.

Why is this good for Cloud?

If Server A handles Request 1, and Server B handles Request 2, Server B doesn't need to know what happened on Server A. This allows us to put a Load Balancer in front and randomly distribute traffic.

2. Managing State in Azure

If the app serves a user session, where do we keep the data? We offload it to a dedicated state store.

The Problem (Stateful)

Storing sessions in the web server's memory (RAM).

• If that VM restarts -> Session lost (User logged out).
• Cannot Autoscale easily.

The Solution (Stateless)

Store sessions in a high-performance database or cache.

• Azure Service: Azure Cache for Redis or Azure Cosmos DB.
• Architecture:
  [ User ] -> [ Load Balancer ] -> [ Web App Scale Set ] -> [ Azure Redis Cache ]

Now, any Web App instance can fetch the user's session from Redis. You can scale the Web Apps from 2 to 200 without breaking user logins.

💡 Hinglish Explanation (Bhulakkad Server)

• Stateless (Gajini): Server ki memory kamzor hai. Har baar jab aap aate ho, woh puchta hai "Aap kaun?". Isliye aapko apna ID card (Token/Cookie) har baar dikhana padta hai.
  • Fayda: Kyunki server ko aap yaad nahi, aap kisi bhi doosre server ke paas ja sakte ho. Koi fark nahi padta.
• Stateful (Yaadaash): Server aapko yaad rakhta hai. "Are Sharmaji, aaiye, wahi purani chai lenge?".
  • Nuksan: Agar woh specific server chutti pe gaya (Crash), toh doosra server aapko pehchanega nahi.

💡 Key Takeaway

For highly scalable cloud apps on Azure:

• Compute (VMs/App Service) should be Stateless.
• State should be externalized to Azure SQL, Cosmos DB, or Redis Cache.