Pregunta

We currently have a monolithic application. Currently an API end-point will look something like:

public async Task<IActionResult> Post([FromBody]ContactViewModel model) {
    //... update the entity in the database

    //Then perform tasks...
    TriggerRegisteredWebhooks(model);

    SendNotifications(model);

    EmailContributors(model);

}

We are looking at introducing a more services type approach to help with some scaling and reliability issues. I've been looking at introducing an PUB/SUB event systems (Azure Service Bus) which services can then subscribe to:

Service Arch

We would then do something like this in our API application:

public async Task<IActionResult> Post([FromBody]ContactViewModel model) {
    //... update the entity in the database

    PublishEvent("Contact.Updated", model);
}

We store all the underlying data in SQL.

Option 1

When publishing an event, is it best practice to include the JSON model for the data with the event, such as:

{
    "topic": "Contact.Updated",
    "message": { ... ContactViewModelJSON ... }
}

Option 2

Or should we simply publish the ID and each service then directly queries the DB to get the data:

{
    "topic": "Contact.Updated",
    "message": 123
}

Option 1 would mean any changes to our JSON schema may break services.

Option 2 would mean each service would query the DB, which could add a lot of necessary calls.

Looking for some advice for best practice/typical approach to this? Or any better suggestions.

¿Fue útil?

Solución

If you are implementing microservices, keep in mind that each one should have its own database. No other service should be able to access that database, only the owner app. So, to share information you have 2 options: 1. Provide an API so the other services can use, or 2. Send the complete data information with your event.

The second approach is actually what I would do since one more API could add some delay to your whole process.

Licenciado bajo: CC-BY-SA con atribución
scroll top