EventStoreDB and Microservices: Database per microservice vs Shared database

EventStoreDB
1

Hello,

A best practice when adopting microservice architecture is segregating data using the “One Database per Microservice” strategy. This pattern generally has some advantages (no single point of failure, improved scalability) and some drawbacks (higher costs, more infrastructure to maintain).

Using EventStoreDB, it seems to me that this approach also has another very important implication:
Segregating the db instance you can’t rely on the provided “subscriptions mechanism” to enable communication between microservices.

This means that if you want to go with the “One Database per Microservice” and EventStoreDB, you must implement integration logic into private subscriptions.

For example:

image
image676×627 56.7 KB

Instead, by adopting the “Shared DB instance” strategy, we could rely on the internal subscription mechanism also to implement microservices intercommunication.

For example:

image

Said that:

  • Is there a suggested approach using “EventStoreDB”?
  • Supposing to choose the “One database per microservice” strategy: which type of subscription one should use to implement the “integration” logic? “Catch up” or “Persistent subscriptions”? I would say the latter, because of the “automatic checkpointing” and “at-least-once” delivery provided out of the box.

Thank you

2

That’s a large topic and is highly dependent on the failure mode you can accept in your architecture.

  • A single DB for a set services that for reasons may fail together and subscriptions between them is ok

    • you need to be careful with data ownership though

  • catch-up VS persistent: that depends on ordering: persistent subscription don’t have ordering guarantees

  • a single broker in the middle may also be enough ( provided you accept that your integration will have the broker as the main single point of failure)

  • multiple broker instance grouping set of services and an owner for that particular broker instance mitigates the above.

it all boils down to the trade-off you want to make when some piece of the overall system fails

and you can also mix integration patterns ; for instance sending notifications to services that will then fetch some data in RPC fashion ( let’s say a document ) from the origin.

3

Yves, thank you for your comments.

I totally agree with the fact (as with anything in computer science :slight_smile: ) that the right choice depends on the specific use case.