Stateful-vs-Stateless Architecture Breakout Takeaway Points

1
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

2
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

3
Stateful-vs-Stateless ArchitectureBreakout
Takeaway Points

• Designing interdependent systems
• Assumptions of what layer i offers to layer i1
• Often change during failure/attackcan we still
  function during that time?
• Need to devise architecture that is evolvable and
  correctable over time