Event sourcing, CQRS and database in Microservice

Question

I am quite new in context of Micro-service architecture and reading this post : http://microservices.io/patterns/data/event-sourcing.html to get familiar with Event sourcing and data storage in Microservice architecture. I have read many documents about 3 important aspect of system :

1. Using event sourcing instead of a simply shared DB and ORM and row update
2. Events are JAVA objects.
3. In case of saving data permanently , we need to use DB (either relational or noSQL)

Here are my questions :

1. How database comes along with event sourcing? I have read CQRS pattern, but I can not understand how CQRS pattern is related to event store and event objects ?

2. Can any body provide me a complete picture and set of operations happens with all players to gather: CQRS pattern , Event sourcing (including event storage module) and finally different microservices?

3. In a system composed of many microservices, should we have one event storage or each microservice has its own ? or both possible ?
4. same question about CQRS. This pattern is implemented in all microservices or only in one ?
5. Finally, in case of using microservice architecture, it is mandatory to have only one DB or each Microserivce should have its own ?

As you can see, I have understood all small pieces of game , but I can not relate them together to compose a whole image. Specially relevance between CQRS and event sourcing and storing data in DB. I read many articles for example :

• https://ookami86.github.io/event-sourcing-in-practice/
• https://msdn.microsoft.com/en-us/library/jj591577.aspx

But in all of them small players are discussed. Even a hand drawing piece of image will be appreciated.

Answer 1

How database comes along with event sourcing? I have read CQRS pattern, but I can not understand how CQRS pattern is related to event store and event objects ?

"Query" part of CQRS instructs you how to create a projection of events, which is applicable in some "bounded context", where the database could be used as a means to persist that projection. "Command" part allows you to isolate data transformation logic and decouple it from the "query" and "persistence" aspects of your app. To simply put it - you just project your event stream into the database in many ways (projection could be relational as well), depending on the task. In this model "query" and "command" have their own way of projecting and storing events data, optimised for the needs of that specific part of the application. Same data will be stored in events and in projections, this will allow achieving simplicity and loose coupling among subdomains (bounded contexts, microservices).

Can any body provide me a complete picture and set of operations happens with all players to gather: CQRS pattern , Event sourcing (including event storage module) and finally different microservices?

Have you seen Greg Young's attempt to provide simplest possible implementation? If you still confused, consider creating more specific question about his example.

In a system composed of many microservices, should we have one event storage or each microservice has its own ? or both possible ?

It is usually one common event storage, but there definitely could be some exceptions, edge cases where you really will need multiple storages for different microservices here and there. It all depends on the business case. If you not sure - most likely you just need a single storage for now.

same question about CQRS. This pattern is implemented in all microservices or only in one ?

It could be implemented in most performance-demanding microservices. It all depends on how complex your implementation becomes when you are introducing CQRS into it. If it gets simpler - why not implement it everywhere? But if people in your team become more and more confused by the need to perform more explicit synchronisation between commands and queries parts - maybe cqrs is too much for you. It all depends on your team, on your domain ... there is no single simple answer, unfortunately.

Finally, in case of using microservice architecture, it is mandatory to have only one DB or each Microservice should have its own ?

If same microservices sharing same tables - this is usually considered as an antipattern, as it increases coupling, the system becomes more fragile. You can still share the same database, but there should be no shared tables. Also, tables from one microservice better not have FK's to tables in another microservice. Same reason - to reduce coupling.

PS: consider not to ask coarse-grained questions, as it will be harder to get a response from people. Several smaller, more specific questions will have better chance to be answered.