1 / 3

Stateful-vs-Stateless Architecture Breakout Takeaway Points

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

hyacinth-roy
Download Presentation

Stateful-vs-Stateless Architecture Breakout Takeaway Points

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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

More Related