At the start of my career as a software engineer, I worked closely with a teammate who specialized in frontend development. In our small startup, he handled the frontend while I focused on the backend. One term he often used was stateless API and stateful API. To read the story for free please visit here.

At that time, I wasn’t familiar with these concepts. Instead of asking him directly, I would quietly research and learn on my own.

As I grew as an engineer, I realized that newcomers often encounter technical jargon they don’t fully understand. We tell ourselves, “I’ll learn this later,” but often forget to follow up. One such commonly used term is stateful and stateless servers. Let’s explore what these mean in simple terms.

Stateful Server

To understand what a stateful server is, let’s move away from software engineering for a moment and use a relatable real-world analogy.

Imagine you visit a restaurant and place an order with the manager. The manager assigns a server (waiter) to your table, and the waiter takes detailed notes about your order — spice preferences, any allergies, special requests, etc.

These notes represent your state. Only this particular waiter knows your preferences. If you want to modify your order or check its progress, you must interact with the same waiter. If another waiter or the manager tries to help, they won’t have the information because it was only noted by your original server.

In this setup, if your waiter is unavailable, no one else can assist you effectively. The restaurant relies on this stateful design, where the server (waiter) is responsible for keeping track of and maintaining the state.

Similarly, in software, a stateful application maintains the client’s state on the server. Any subsequent requests from the same client must go to the same server. This is usually achieved by configuring a load balancer with sticky sessions enabled. This ensures that the server is always aware of the client’s context.

Stateless server

A stateless architecture, on the other hand, doesn’t mean there’s no state at all. Instead, the state is stored externally, outside the server. The server itself doesn’t retain any client-specific information between requests.

Let’s revisit the restaurant analogy: Imagine the waiter takes your order but doesn’t rely on a personal notepad. Instead, they record your order on a centralized computer system. This system is accessible to all waiters. Now, any waiter can check or update your order without relying on the original server who took it.

In software terms, this central system could be a database where the client’s state is stored. Each request sent to the server is independent, and the server fetches the required state from the database if needed.

Conclusion

If we think about network protocols, HTTP is a classic example of a stateless protocol. Each HTTP request is independent and contains no memory of previous requests. The server treats every request as an isolated transaction, without maintaining client state.

In contrast, TCP is connection-oriented and stateful. It establishes and maintains a continuous communication channel between two devices (e.g., a client and server) until the connection is explicitly terminated.

Key takeaway:

State is either maintained on the server (stateful architecture) or in a separate database (stateless architecture). The choice between these approaches depends on the specific requirements and design goals of your application.