Downloaded 37 times
Uploaded byTopu Newaj
CQRS : Introduction
The document discusses the architectural patterns for enterprise applications, focusing on Command Query Responsibility Segregation (CQRS) and event-driven architecture. It examines the challenges of database operations, the importance of separating read and write services, and the benefits of employing a denormalized database for read operations. Additionally, it highlights the growing adoption of these patterns by companies such as Microsoft and Selise in building scalable applications.
CQRS : Introduction
- 1. CQRS : Introduction Shah Ali Newaj Topu, CTO, Selise
- 2. How do wearchitect enterprise application Application Layer (Client) Service Layer Business Logic Layer Data Access Layer Sec uri t y Loggi ng Relational Database
- 3. A typical requestLifeCycle newContactID=ContactService.AddContact(Contact) return ContactManager.AddContact(Contact); If(Validate(Contact)) return ContactRepository.Add(Contact) Insert into… return newContactID Relational Database
- 4.
- 5.
- 6.
- 7. and taken backto the grid
- 8. Why we wait? Because it takes some time to add the information to the Database and return us the newly created ID.
- 9. Why database takestime? ● More write operation might be in progress. ● Lot of read operation might be in progress. ● Some request itself might take longer than others because it has to update multiple tables. ● And so on.
- 10. What happens whenwe read data contactList=ContactService.GetContacts() return ContactManager.GetContact(); return ContactRepository.Get() Select from ...join…join return contactList Relational Database
- 11.
- 12.
- 13. We have 2wait screens Can we get rid of them?
- 14. Why we wait? ● Lots of Joins in Select query ● There was some write request from other users which locked the table we were trying to read.
- 15. Why we haveJoins Because we have Normalized Database
- 16. And we needNormalized database because
- 17. Normalization slows downread operation The best READ performance can be achieved from a Denormalized Database where data is duplicated and found in columns rather than rows.
- 18. Can we havebest of both Imaging you have one service that does all the WRITE operation and updates your Normalized Database and ensures data integrity. Then you have one service that reads the data from a Denormalized Database. And somehow these two Databases are synchronized.
- 19. Separation of Readand Write contactList=ContactREADService. GetContacts() return ContactManager.GetContact(); return ContactRepository.Get() Select * from Contact return contactList Denormalized Database newContactID=ContactWRITEService. AddContact(Contact) return ContactManager.AddContact (Contact); If(Validate(Contact)) return ContactRepository.Add(Contact) Insert into… return newContactID Sync Normalized Database
- 20. We can deploythem separately More Read Service Less Write Service
- 21. But this justa small improvement We still need the loading screen because Sync will take time and if we make a call to the read service before the sync is done we will not get the data we are looking for.
- 22. But lets lookback
- 23. We have allthe data on the Client We refresh our grid to show the newly added row by doing a query to the read service. Why? We have all the data in the client because user just now entered it, remember? In the add contact screen. Why we need to query to the read service for data which we already have?
- 24. So.. Can weadd the row to the grid without making a call to the Read Service?
- 25. But we stillhave to wait for Write Remember our Write Operation returns an ID. We need this ID to uniquely identify the Data we are writing. What if the Write takes long? We will need a wait for that anyway!
- 26. Redefining ID Whatif we stop asking the Database to create this id and send it back? What if we generate the ID at the client? What if the ID is a GUID?
- 27. Redefining ID ContactWRITEService.AddContact (Contact) ContactManager.AddContact(Contact); If(Validate(Contact)) ContactRepository.Add(Contact) Insert into… Normalized Database
- 28. Client becomes independent For each data change client can now make a call to the write service and without waiting for return value it go back to do the next operation. Write service can take its time to perform the operation and update the read database accordingly.
- 29. Read and Writeare independent Read services only reads data Write services only changes the data.
- 30. Command Query ResponsibilitySegregation. ● A Pattern ○ Not an Architecture ○ Not an Architectural style ○ Not a principal Udi Dahan Greg Young ● Based on Command Query Separation Principle
- 31. CQS Principal Command–queryseparation (CQS) is a principle of imperative computer programming. It was devised by Bertrand Meyer as part of his pioneering work on the Eiffel programming language. It states that a method should either change the state of an object or return a result but not both.
- 32. The Reactive Manifesto Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than disaster. Reactive Systems are highly responsive, giving users effective interactive feedback.
- 33. Reactive Systems are ● Responsive ● Resilient ● Elastic ● Message Driven
- 34. Necessary patterns CQRS Event Sourcing Domain Driven Design Event Driven Architecture
- 35. How does itlook
- 36. Who is doingit? Microsoft In July 2012 Ms started a project called CQRS Journey. The project is focused on building highly scalable, highly available and maintainable applications with the Command & Query Responsibility Segregation and the Event Sourcing patterns. Now they published a book and a fully documented source for implementing CQRS.
- 37. Who is doingit? Java: ● AxonFramework ● Jdon Framework Scala: ● eventsourced
- 38. Who is doingit? Selise: We are building Publiweb, a massive multi module, multi tenant , SaaS based highly scalable application using CQRS, Event Sourcing and Domain driven design for Swiss E-Gov.
- 39. What no onetold me When you are asked to develop a scalable web application you are indeed asked to build a distributed system.
- 40. What is aDistributed System Write Read
- 41. What that hasto do with Web App
- 42. Fallacies of DistributedComputing ● The network is reliable. ● Latency is zero. ● Bandwidth is infinite. ● The network is secure. ● Topology doesn't change. ● There is one administrator. ● Transport cost is zero. ● The network is homogeneous.