1. CQRS
Tim Mahy

2. Agenda
• Why
– History
– Current architectures & challenges
• What
• Real life case

3. • Command
• Query
• Responsibility
• Segregation

4. • About the business and looking at the
business with regards to
– collaboration
• Not only for high-scalability requirements
• A set of difficult questions
• A fresh look at architecture and code design

5. • Touches
– DDD
– NoSQL
– BDD
– EDA

11. • TODO: Data Entry screen for a company

12. But what has changed
• Increase of
– Commands
– Queries
– Searching
– Users and Collaboration

13. Collaboration
• Locking strategies

14. Traditional architecture
TODO:
• Layers / Tiers
• Transformations
• Structured data

15. Let’s validate this design
• TODO: validate against new challenges
• + talk a bit about caching and ORM etc

16. <asp:DataList ID="DataList1" runat="server" DataSourceID="LastUsersDataSource">
<ItemTemplate>
<asp:Label ID="NameLabel" runat="server" Text='<%# Eval("Name") %>' />
<br />
2 layer
</ItemTemplate>
</asp:DataList>
<asp:SqlDataSource ID="LastUsersDataSource" runat="server" ConnectionString="<%$
ConnectionStringsMyConnectionString %>"
Query model
SelectCommand="SELECT [Name], [InsertDateTime] FROM [LastUsers] ORDER BY [InsertDateTime] DESC">
</asp:SqlDataSource>

17. Let’s go back to the essence
• Pattern to segregate approach for:
– Commands
– Queries
• Everything in ALM is touched by this

18. Commands
• Task driven UI

19. Commands
• Serialized method call on a root aggregate
• Can say NO
• Check business rules
• Can be sync/async
• Work best in a DDD world
– 3 layered
– No more worries for ‘slow’ reading

20. Queries
• Is not search!!
– Lucene.NET
– Google applieance

21. Queries
• Stale data
TODO: Mockup  straten

22. Queries
• Return DTO
• Less layered approach
• Have their own state (persisted viewmodel)
• No influence on command side
• Easy domain
• Datastore  does it need to be relational?

23. But how do we come to these
persisted viewmodels
• Commands deliver business events (past
tense)
• Business events mutate state on truth
datastore and in persisted viewmodels

24. UI DataStore
Queries
Subscribe
UI Commands
EventBus
Business Logic Publish
Truth (optional)

25. Business events sourcing
• Keep all business events
• Replay business events when needed
– Snapshotting strategy when required
• Truth database can also be only these events
in an ideal world

26. • Demo: event sourcing shopping cart

27. Other team members
• Testing
– Given * events
– When * command
– Then * events

28. Tooling
• SimpleCQRS
• NServiceBus

29. Real life case
• VECOZO
• Project
• Requirements
• How CQRS helped us
• Statistics

30. Project
• Receives all the health insurance information
from the Netherlands
• Allow healtcare parties query to check for
insurance and details
• Give insights back to the insurance companies
and government

31. Requirements
• Every query should respond below 20ms
• Traditional .NET stack:
– MS SQLServer 2008 R2
– WCF SOAP webservices
• Must be able to respond to 600 query
requests per second
• Must be able to process all data within 4
hours

32. CQRS (zoals meest bekend)
UI DataStore
Queries
Subscribe
UI Commands
EventBus
Business Logic Publish
Truth (optional)

33. CQRS (zoals in AVG)
DataStore
Webserv Queries
Receive
ices
EventBus
Commands
PCS Business Logic Publish changes
Truth

34. Technical choices
• Event Sourcing is stored in MS SQLServer
• All queues are Sql Server Service Broker Queues
• Denormalizers are CLR stored procedures in
query databases
• Query databases are all eventually consistent, no
synchronisation context over health insurance
companies
– Very hard normalized (one table)
– Dirty reads
– Correction of data in-memory after reading

35. Statistics & Conclusion
• Statistics:
– Event Sourcing: 190 GB
– Persisted views: 80 GB
– 72 health insurance companies deliver 80M insurance packages a day
which are validated with commands
– Which results in 169.000 business events a day
• Very easy to test
• Very easy to manage when
– Failure
– Failover
• Staged deployment
• Future proof
– No more migrations ever
– New systems just need to understand the business events

36. POC Event Sourcing:
QueueUnlimited

37. QueueUnlimited
• Open Source project
• Very easy architecture for event sourcing

38. Queue Unlimited – no subscribers
• How it works
PublishEvent SP InitiatorService
RootService
Stored Procedure
SSB Service
SSB Queue enabled
SSB Queue disabled
Activation SP enabled
Activation SP disabled
SSB Dialog / Send

39. Queue Unlimited – Adding a subscriber
PublishEvent SP InitiatorService
RootService
Activated
Subscriber 1 Service Replay 1 Service
Not
activated
Some app

40. QUEUE UNLIMITED – Adding another subscriber
SendEvent SP Initiator service
Root Service
Activated
Subscriber 1 Service Replay 1 Service
Activated
Some app
Not
Subscriber 2 Service Replay 2 Service
activated
Some app

41. QUEUE UNLIMITED – Garbage collection
SendEvent SP Initiator service
Root Service
Activated
Not
Subscriber 1 Service Subscriber 2 Service Replay 2 Service
activated
Some app
Some app

42. QUEUE UNLIMITED – Scale out
SendEvent SP Initiator service
Root Service
30% messages
Subscriber 1 Service Replay 1 Service
30% messages
Some app Replay 1 Service 2
Replay 1 Service 3
40% messages
42