11. Scale Out
Functional Partition
Increase overall capacity by separating bounded
contexts
Data Partitioning
Increase capacity within a functional partition
12. Scale Out, Industry Trends
Cloud
Elastic Expansion
Rich Internet Applications
HTML5/JS, as well as Flex/Silverlight
So-ware as a Service
14. Available
A system that
Is in an operable state
Can provide expected functionality when needed
15. Living in the Clouds
Available
24/7, online, anywhere
Response time is a dimension of availability
95th percentile is key latency metric
16. Partial Availability
Data Partitioning
A single database failure only impacts data on that
server
System can be partially available for a subset of
customers
22. Consistency
Changes to values are consistent in a system
An updated address
A changed telephone number
An additional family member
The inventory level of an item
29. Atomic
Modifications are not
accessible to concurrent
transactions
Lack of isolation can
lead to inconsistent state
30. Atomic
Completed transactions
survive system failures
31. ACID Defined, circa 1983
State of the art system
Single machine
Vertically scaled up
DB/2 (or even ISAM)
32. Distributed Transactional
2PC
Two-phase commit protocol
Averages availability of involved systems
System A (99.9%, 43m) x System B (99.9%, 43m)
Results in combined availability of 99.8% (86m)
33. Temporal Inconsistency
If I pick up a book at the bookstore, and walk around
with it for an hour, another customer is unable to
purchase that book.
Once I decide to buy in on Amazon instead, a
bookstore employee will gladly replace the book on
the shelf
I go on enjoying my coffee knowing I saved $4.20
35. Eventual Consistency
Make temporal consistency windows explicit
Command-Query Responsibility Segregation
(it’s just command query separation)
www.msteched.com/2010/NorthAmerica/ARC302
Persistent View Model
36. Keep Transactions Internal
Transactions should not cross service boundaries
Avoid adding remote resources to the DTC
Avoid cross-database transactions
37. Protocols
Create protocols for cross-functional transactions
Maintain the state of each exchange in each
participating functional partition
Example in action
Magnum.StateMachine
Magnum.Channels
Atomic - All or Nothing
Consistent - from one consistent state to another with each transaction
Isolation - data in a transaction in inaccessible until the transaction is complete
Durable - recoverable in case of a system failure
Atomic - All or Nothing
Consistent - from one consistent state to another with each transaction
Isolation - data in a transaction in inaccessible until the transaction is complete
Durable - recoverable in case of a system failure
Atomic - All or Nothing
Consistent - from one consistent state to another with each transaction
Isolation - data in a transaction in inaccessible until the transaction is complete
Durable - recoverable in case of a system failure
Atomic - All or Nothing
Consistent - from one consistent state to another with each transaction
Isolation - data in a transaction in inaccessible until the transaction is complete
Durable - recoverable in case of a system failure
Atomic - All or Nothing
Consistent - from one consistent state to another with each transaction
Isolation - data in a transaction in inaccessible until the transaction is complete
Durable - recoverable in case of a system failure
Atomic - All or Nothing
Consistent - from one consistent state to another with each transaction
Isolation - data in a transaction in inaccessible until the transaction is complete
Durable - recoverable in case of a system failure
Atomic - All or Nothing
Consistent - from one consistent state to another with each transaction
Isolation - data in a transaction in inaccessible until the transaction is complete
Durable - recoverable in case of a system failure
Atomic - All or Nothing
Consistent - from one consistent state to another with each transaction
Isolation - data in a transaction in inaccessible until the transaction is complete
Durable - recoverable in case of a system failure