Fighting Bottlenecks with CQRS

More at http://verraes.net/ or http://twitter.com/mathiasverraes

How can you sell a gazillion tickets in an hour? This talk will explain how to use CQRS, Event Sourcing, and a strong focus on the problem domain to build a system that deals with peaks, reporting, and occasionally connected devices.

ResearchGate DevDay
Berlin, November 30, 2013

Transcript

1. Fighting Bottlenecks with CQRS/ES ResearchGate Berlin Nov 30, 2013 Mathias Verraes @mathiasverraes verraes.net
2. Student of Systems Meddler of Models Labourer of Legacy
3. Blog verraes.net DDDBE domaindriven.be Podcast elephantintheroom.io
4. Business Problem A Simplified Model Command/Query Responsibility Segregation Event Sourcing Read Model Projections Eventual Consistency
5. Business Problem
6. Sell a gazillion concert tickets to desperate fans … in a hurry!
7. Don’t crash during peaks Don’t annoy our customers Don’t sell more than we have
8. A Simplified Model
9. Model invariants as a Presale Aggregate?
10. #reservedTickets #soldTickets #availableTickets Presale # Tickets
11. Model invariants as individual Ticket Aggregates
12. reserved sold available Individual Ticket status
13. Command/Query Responsibility Segregation
14. Client Remote Façade Application Services Domain Model ORM Database
15. Highly cohesive Read + Write Model?
16. Bottleneck
17. Client Database Database Remote Façade Application Services Domain Model ORM Eventually Consistent
18. CQRS challenges the assumption that reading and writing are supposed to share the same abstractions.
19. CQRS challenges the assumption that reading and writing are supposed to share the same models.
20. CQRS challenges the assumption that reading and writing are supposed to share the same databases.
21. CQRS challenges the assumption that reading and writing are supposed to share the same applications.
22. Segregation of read and write is a radical form of decoupling.
23. Client Domain Model Remote Façade Remote Façade Application Svcs Application Svcs Domain Model ORM ORM Database Database
24. Radical!
25. Client Write Model Read Model
26. Client Write Model Read Model DTO Commands Events
27. Interact with State Guard Invariants Project State
28. Task Based UI Event Store Polyglot Persistence
30. Event Sourcing
31. TicketWasReserved [ ticketId, forUser, onDate ]
32. Ticket state = Ticket history ! TicketWasSold [ toUser ] TicketWasReserved [ forUser, onDate ] ReservationWasReleased [ ] TicketWasReserved [ forUser, onDate ] TicketWasPrinted [ inPresale ]
33. Mature domains already work this way ! AccountWasDebited [ 20 ] AccountWasDebited [ 10 ] AccountWasCredited [ 100 ] AccountWasOpened
34. BankAccount { debit(amount) { guardThatAccountIsNotOverdraft(amount) recordThat( new AccountWasDebited(amount) ) } }
35. BankAccount { apply(AccountWasDebited event) { amount = amount - event.amount } }
36. BankAccount { getRecordedEvents() {} reconstituteFromHistory(eventHistory) {} }
37. Read Model Projections
38. TicketWasSold TicketWasReserved ReservationWasReleased TicketWasReserved TicketWasPrinted Ticket ! !
39. TicketWasSold TicketWasReserved ReservationWasReleased TicketWasReserved TicketWasPrinted AvailableTicket TotalNumberOfAvailableTickets AverageNumberOfTicketsPerBuyer AverageNumberOfReleasesPerTicket
40. Eventual Consistency
41. Writes are immediately consistent Reads are eventually consistent
42. Many issues stemming from eventual consistency can be solved in the user interface
43. A Ticket can only be sold once. How do we know it’s available?
44. Get a batch of x*2 PossiblyAvailableTickets ! ReserveTicket ack/nack loop while acks < 3 To buy x tickets:
45. More? ! Testing Context Mapping Event Storming Process Managers Occasionally Connected Systems Reporting Legacy Integrations …
46. Questions? verraes.net @mathiasverraes