Upload
hyacinth-roy
View
19
Download
1
Embed Size (px)
DESCRIPTION
Stateful-vs-Stateless Architecture Breakout 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 - PowerPoint PPT Presentation
Citation preview
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