The document discusses event sourcing and CQRS architectures for building scalable applications. It describes how event sourcing allows appending only events forward in an immutable way, enabling custom query models and easy scaling. Event sourcing provides benefits like high performance, easy testing by replaying events, and analyzing business events over time rather than just the current state. The document contrasts this with standard architectures and discusses eventual consistency, task-based UIs, and using an event-driven architecture with a message bus to execute loosely coupled workflows across systems.
3. Performance with 3NF
❖ Launching brand new product
❖ 000s hits per second
Products
Product
Comments
Product Reviews
Product Inventory Best Sellers
4. Losing data
❖ Who said it was okay to remove data?
User Shopping Cart
User Id Product Quantity
1
Tennis
Racquet
1
1
Samsung
Note 3
1
1 30” Monitor 2
DELETE FROM UserShoppingCart
WHERE Product = ’30” Monitor’
5. Audit / History Logs
AccountId Balance When
1234 0
01 Jan
2015
1234 1000
05 Jan
2015
AccountId Balance
1234 $1000
Trigger /
Event
Based /
Explicit
Account Account History
6.
7. Event Sourced Shopping Cart
Cart
Created
3 Items
Added
1 Item
Removed
Checked
Out
WRITE SIDE
Task Based UI Projection
READ SIDE
8. Advantages of Event Sourcing
❖ Fantastic Performance
❖ Events are appended only - forward only.
❖ Allows our query model to be custom made for each Task Based UI
❖ Events are immutable
❖ Very easy to scale up
❖ Easier to test
❖ Reply events to replicate issues
❖ Smoke test - Rerun REAL production scenarios
❖ Business Value - allows you to analyse behaviour and events
❖ Not limited to “current state”
12. Eventual Consistency
❖ Eventual Consistency sounds bad
❖ But in reality, most of us are dealing with it without realising.
❖ Part of distributed computing - CAP Theorem
❖ Consistency
❖ System Availability
❖ Network Partitioning
❖ Many ways to handle it
13. Task Based UI
❖ a.k.a Inductive UIs
❖ Opposite to CRUD UI
❖ User Interface should be presented in terms of the problem
domain
❖ Example
❖ User Interface should be presented for one task, in a clear
fashion
❖ Works well with Domain Driven Design
❖ Helps in naming Commands / Requests (Queries)
14. Event Driven Architecture
❖ This is a top level architecture pattern
❖ Domain events are published
❖ Anyone can subscribe to them
❖ Medium - Message Bus
❖ Execute a loosely coupled, cross system workflow
Editor's Notes
Who models their database in 3NF?
When 95% of our transactions on our system are read, why are we optimising for write?
We learnt it was the way.. at uni. Space is valuable.
Shopping cart performance problem.
New product launch. High profile.
Gets slammed. Inventory, Reviews, Comments, Top Seller, Sales counts
There was some research done and found there is a correlation between items removed from a cart within x minutes of checkout and purchasing that product within the next 6 months.
Now.. getting this data in 3NF would be almost impossible - So lets start capturing the data.
And produce a report, but the report has no data - because we haven't capturing anything yet. Damn!
How do people Log?
Can anyone prove that their log is 100% correct and valid
How do banks do it?
This is how databases do it.
Event Sourced Shopping Cart
Business Behaviour
A single model cannot be appropriate for reporting, searching and transactional behaviours.
Talk about CQS / CQRS
Requests and Commands named in Ubiquitous Language
Query store can be one table per UI View (Task Based UI)
Query store can be whatever suits the problem
Is not a property of CQRS!
More so integrating between two systems (Event Sourcing)
SignalR
Example: Change of Address
Typo
Moved address
Additional address
