© 2001 Stanford Distinguishing P, S, D state n Persistent: loss inevitably affects application correctness, cannot easily be regenerated l Example: billing record in a persistent DB n Soft: regeneratable, occasional loss tolerable l Example: memoized result of a computation l Example: load balancing information, routing tables n Degradable: probabilistic guarantee of recall l Example: cached session state l Useful if we can characterize the cumulative distribution function of degradation vs. time (open issue) l Related to harvest/yield (next time)

© 2001 Stanford Distinguishing Interactivity: R, W, N n Reads must track interactive performance l But writes are infrequent l Example: static or dynamic content Web server n Writes must track interactive performance l Example: securities trading n No interactive constraints l Example: background/batch processing subsystems (Amazon and Buy.com do this) n These have different user-perceived failure modes

© 2001 Stanford Decomposition Example

© 2001 Stanford Why Do Decomposition? (toy example) n Consider an alternative implementation for a (W,P)- semantics multi-node collector for a hit counter l Each node maintains in-memory counter: (W,D) semantics l Periodic checkpoints get flushed to “master” counter: (N,P) semantics l To read hit counter, arrange for master to periodically broadcast “stale” master copy to each node, and allow any node to serve “stale” value: (R,D) semantics n Note tradeoffs: consistency vs. failure management l Local copies of counter can be in volatile-only memory! l Same principle used in SNS load balancer l Similar principle used in harvest/yield tradeoffs in Inktomi

© 2001 Stanford Example 3: Application Decomposition n Applying harvest/yield tradeoff to application decomposition of a canonical e-commerce site Billing Profiles Catalog Internet $ $ FE W W W T W W W A

© 2001 Stanford Component State Management n User profiles l Read often, write infrequently l Must persist across sessions n Online merchandise catalog l Read-only database l Presentation should depend on user preferences n Shopping cart l Read and write frequently l Need not persist across sessions n Billing (transactional DB)

© 2001 Stanford Degradable State: Shopping Cart n Shopping cart is more “state-intensive” than billing l Shopping cart subsystem manipulates more incremental state per user than billing l But, shopping cart is an “optimization” l We can reflect this into provisioning/growth n One idea: Keep cart contents in a cache l Not a database! l Non-ACID l Soft state by definition

© 2001 Stanford Per-Component Failure Modes l Shopping cart can be periodically checkpointed to user profile l Transformation & aggregation modules can present catalog based on user input Billing Profiles Catalog Internet $ $ FE W W W T W W W A

© 2001 Stanford Degradable State, cont’d. n What’s the probability of losing the shopping cart? l HW or SW failure in cache (e.g. transient node failure, write corruption) l Eviction: rate depends on cache size and working set size; can grow cache incrementally to fix problem n What happens to users when cache is thrashing? l Turn off shopping cart for everyone? l “Use at own risk” shopping cart? l Rent some machines at high cost, until new ones arrive? l Probably cheaper to deploy a Web cache node than a new DB node!

© 2001 Stanford Decomposition Summary n Implementation of demanding, high-performance applications forces us to make tradeoffs l Availability vs. consistency (relaxing ACID) l Failure management vs. perfect information n Many things are probabilistic, whether we like it or not l Decomposition frameworks allow us to make this explicit, and manage them to our advantage l Next time: related concept -- how harvest/yield tradeoffs can be mapped directly to engineering mechanisms for partial-failure management l Challenge: Quantifying things like degradation and levels of tolerance

© 2001 Stanford Synergy n Decomposition may naturally result in components that are more easily recoverable/restartable l e.g. converting (W,P) to combination of (W,D), (N,P), (R,D) separates W from P l (W,D) and (R,D) have implementations that admit of trivial failure recovery (restartability) n Orthogonal mechanisms can often be used to protect components with this property l Timeouts, firewalls, sandboxes, guards l Build components so their semantics are compatible with the use of orthogonal mechanisms