Stateless vs Stateful

Stateless

The functionalities of pure stateless services are quite limited, most likely we still need to save states to somewhere; if not stored locally, then they have to go to the database layer.

So it works like this: a client makes a request; the stateless service talks to the database to get some data; the service does some computation and send the response to the client. The data is not persisted on the service instance, and the next request may be load balanced to a different instance. If there's no cache, this is quite wasteful.

• pros:
  • easy to scale horizontally
  • easy to load balance(e.g. simple round-robin)
• cons:
  • state stored in databases, and round trips to the databases increases latency
  • need a caching layer to mitigate the latency problem
  • once the application outgrows the single database instance, either sharding or a NoSQL database is needed, which may sacrifice strong consistency

Stateful

• pros:
  • data is right on the server, no need to hit database, low latency
  • data can be persisted on the server after the request is handled, the requests from the same client can be routed to the same instance, so the following requests can reuse the data, or the "state"
  • can open up a persistent HTTP connection or a TCP connection
• cons:
  • if the connection breaks the stickiness is gone, and the next request will be load balanced to another server
  • bad load balancing, easy to overwhelm a single server with too many connections