Stateful-vs-Stateless ArchitectureBreakout Takeaway Points Bridge analogy

Not one architecture for all bridges (suspension, other types, etc)

Focus on 4 types of state App: user login name, ssn, shopping cart… Session: cookie, session id, token Recoverability: checkpoint, who was I talking with

when I crashed? (maybe they should be restarted too)

Configuration: because of access pattern and usage semantics, different type of data

For stateful components: need “killer” component in system

Stateful-vs-Stateless ArchitectureBreakout Takeaway Points Restart at various levels:

JVM method, object, bean, .net Move from systems data to real app logic

Means better visibility into what data is needed for reset State could be list (graph) of restartable components

and “who talks to who” Without right alerts, errors can propogate

Bad battery forced writes bad perf Router example of state reconstruction:

Self correcting, but simple service (routing) Closer to user means few constraints and so few

assumable properties

Stateful-vs-Stateless ArchitectureBreakout Takeaway Points

Designing interdependent systems: Assumptions of what layer i offers to

layer i+1 Often change during failure/attack—can we

still function during that time?

Need to devise architecture that is evolvable and “correctable” over time