View on GitHub

engineering-notes

Notes for engineering

When designing the distributed system/service with large scale, the design of stateless and stateful for the service is always a big discussion.

State usually refers to the information about the user/client, and when processing the client/user’s request, the performed behaviors in server side depends on the state info.

Stateless Design

Stateless means there is no ‘sticky’ knowledge/state about a request or transaction and the service always performs every request as it is first time to request.

UDP protocol is an example designed as the stateless, each ‘transation’ does not depends on the knowledge of previous sent package. While TCP considered as an example for the stateful design, in each transaction the protocol needs to be aware of what packages already received.

Cons & Pros of Stateless Design

Pros:

Cons:

For scenarios has (transaction) state info:

Scenarios

Stateful Design

Stateful means that what the previous transactions/requests done may affect the behavior for current transaction/request.

Usually, stateful design highly depends on a good DevOps system to make sure the whole cluster/system works well.

Cons & Pros of Statefull Design

Pros:

Cons:

Scenarios

Design Tips

This doc will introduce several practices/solutions for designing stateful system.

Stateless and Stateful Design

Whether the service designed as stateless or stateful is totally a trade-off, each design has its own advantages and disadvantages and good fit in different scenarios. However, they are not really exclusive to each other, in some scenarios we need to combine both. Take HTTP and TCP as an example, TCP is transaction-oriented ‘stateful’ design while HTTP is more like a stateless design based on the TCP.

In the real system, you might have the front-tier like the gateway acts as the stateless and the application tier service as the stateful.

References: