The document discusses the concept of "state" in distributed and microservices architectures. It explains that state can exist at the local, service, and system levels. At the local level, state is well-defined and unambiguous. At the service level, state is bounded by context and services have testable behavior. At the system level, emergent behaviors occur and no one is truly comfortable. The document suggests that to deal with system-level state, organizations should measure everything, use abstractions, and establish well-defined processes. An approach is outlined involving consistent data, boundaries between services, defined behaviors, and process rules.

1. State of yer WAN
What does “state” mean in a distributed / microservices architecture ?

2. Local & deterministic
* Well defined unambiguous state
* Developer’s comfort zone

3. “Service” level
* Bounded context
* Testable behaviour
* DDD comfort zone

4. “System” level
* Emergent behaviour(s)
* Is anyone comfortable here?

5. What can we do?
* Measure everything
OLJ 565 M
12 mph
Gary

6. What can we do?
* Abstractions

7. What can we do?
* Process

8. It depends
* Measure
* Abstractions
* Process

9. An approach…
Atomically consistent data
Well defined boundaries
Behaviour
Process rules