CODEWITHSUNDEEP
microservicesdomain-driven-designcqrsevent-sourcing
milandjukic88
milandjukic88

Reputation: 1115

What should be projection primary key on query side - CQRS, Event Sourcing, Microservices

I have one thing that confuses me. I have 2 microservices. One creates commands and other consumes commands and produces events (events are stored in Event Store).

In my example aggregates have Guid as Entity ID, and Guid is created when aggregate is created.

Thing that confuses me is, should that key (generated on write side) be transfered via Event to query side (microservice that created command)? Or maybe query side (projection) should have separate id in read DB. Or maybe I should generate some shared key?

What is best solution here?

Upvotes: 1

Views: 433

Answers (3)

Greg Young
Greg Young

Reputation: 2623

This is kind of an odd question.

Your primary key on a projection could literally be anything or you might not even have one.

There is no "correct answer" for this question ... It depends entirely on the projection.

What if my projection was say just a flattening out of information associated to an aggregate ... As example we have an "order" and we make a row per order showing summary information about that order. Using an "OrderId" here would seemingly make some sense as my primary key.

What if my projection was building out counts of orders by Product? Well then using a "ProductItemId" would make a lot more sense.

What if in either of these cases the Ids themselves ("OrderId" and "ProductItemId") could change? Well then using another key might make a lot of sense.

What if this is an append-only table? I might not even want to have a key.

Again, there is not a ... correct ... answer here there are many situations that you may run into.

Upvotes: 1

Tore Nestenius
Tore Nestenius

Reputation: 19941

I think it all depends on your setup.

If you are doing CQRS, and you have a separate read-service (within the same bounded context), then it is up to the read-side service to model the data as it wish, either reusing the same keys or not.

If you are communicating between two different services (separate bounded contexts) then I recommend you create new primary keys in the receiving service and use the incoming key as a foreign key. Just as you would do with relationships between two tables in a SQL-database.

Upvotes: 2

Neil W
Neil W

Reputation: 9237

I think this depends on your requirements. Is there a specific reason to have different keys?

Given that you are using Guids as your PK, it seems simplest to reuse the PKs assigned by the write side.

Some reasons you might want to keep the keys consistent:

  1. During command processing an ID was returned to the client that they may have cached and should reasonably expect to be able to use that key when querying the read side.

  2. If your write side data is long-lived and there is an bug on your read side output, it is gonna be much easier to debug what went wrong if your keys are consistent on write and read side.

  3. Entities in the write side will use the write side Guid PK of another entity as its FK. When you emit an event for this new dependent entity you would want the read side to be able to build the relationship back to the principal.

Upvotes: 1

Related Questions