Stateless Parts, Stateful Wholes

Everyone says “stateless services scale better.” True. But we still need systems that can remember.

In modern architecture, the mantra is clear: make your services stateless. Stateless services are easier to test, retry, and revert. They scale horizontally and avoid messy side-effects. But when you compose a system entirely of stateless parts, you still need *somewhere* to remember what just happened, what's in progress, and what's next.

That memory often gets pushed into places it doesn't belong like client code or brittle configuration glue. That’s a recipe for bugs, fragility, and most reduced reusability.

A composable service platform takes a different approach: you keep services stateless but build stateful systems using a dedicated, stand-alone shared state service. Then, compute services receive input, produce output, and that is all. The coordination, the memory, the workflow history; all of that lives between the services in a shared place, not inside each service or even in each client.

This makes it possible to support retrying and reverting services when needed, combine services in novel ways unknown to each service themsevles. And all this happens while maintaining clarity about service and system behavior over time.

Key Takeaway
Design your services to be forgetful and your systems to remember. And always keep in mind that state is what holds both service and system together.

Further Reading

For a deeper dive into shared state models, check out “The Growing Medium for API Ecosystems”