Refresh propagated data

[i02coroj]

Hi.
I've got a question around the data propagated across different services: how to refresh it?

Let's consider next scenario:
We want to add a validation in Ordering service to make sure an item exists when creating an order, just in case it was removed hitting the delete endpoint in Catalog service.
To achieve it, we propagate Catalog data into Ordering database (only a few properties, maybe just the Id) so we avoid direct calls from Ordering to Catalog.

With that running in prodution, what mechanism can we use to refresh that propagated data in Ordering service. That could be needed for different reasons:

• A new requirement implying we need to save in Ordering more attributes from the Catalog data.
• A bug in Ordering not saving correctly the propagated data
• ...

Any ideas on how to approach it?

[onurkanbakirci]

Hi @i02coroj .What do you mean with make sure an item exists when creating an order ? Do you want to be sure about units in stock is valid or not etc?

[i02coroj]

Hi @onurkanbakirci , not exactly, I mean to be sure about a product is still in the catalog, just in case somebody has removed it right before creating the order.

It's just a fictitious scenario, not happening at the moment in eShopOnContainer solution, but imagine you cache catalog products into Ordering database to be able to make that validation In Ordering service without hitting Catalog service (which gives you resiliency).

In that scenario, what mechanism could be used to refresh that cache if needed?

[onurkanbakirci]

In eShopOnContainer, order service sends OrderStatusChangedToAwaitingValidationIntegrationEvent to catalog service via MessageBroker(RabbitMQ, Azure Service Bus etc.). Then, catalog service's OrderStatusChangedToAwaitingValidationIntegrationEventHandler class catches this event and checks whether product is valid or not and also checks stock of it (this checks can be expanded by your business requirements). If everything is correct, catalog service sends OrderStockConfirmedIntegrationEvent to order service. So, if there is no product, catalog service will send OrderStockRejectedIntegrationEvent to order service and order process can't continue.

As for your example, if you want to add caching mechanism for products you should implement it into catalog rather than order. Catalog and Order services are two different bounded context and i think that caching catalog data into order service database is not proper way achieving resiliency. And also using Redis which provides distributed caching, will gains to your project much more resiliency.

[i02coroj]

Thanks @onurkanbakirci .
Yeah, that makes sense.
My point is using that approach with OrderStatusChangedToAwaitingValidationIntegrationEvent and OrderStockConfirmedIntegrationEvent means that if Catalog service is down the order cannot be confirmed. Ideally, in complex business scenarios you want to be able to continue with the order even if one of the services is down for some reason.

So, instead of using that approach (totally valid for sure), a possible solution I've seen in some places (and also mentioned by @CESARDELATORRE in some conferences I think) also is to use an event published by Catalog and received in Ordering to save the products in Ordering database (using a different reduced model according to what DDD says). This way, when trying to process the order, we don't need to publish an OrderStatusChangedToAwaitingValidationIntegrationEvent as Ordering service would be able to make the decision.

Question was, in this scenarios, how to re-populate these tables in Ordering database when needed?
I understand it's not a scenario occurring in eShopOnContainers, so thank you anyway.
It's just I haven't found info about that, not even in microservices book from @CESARDELATORRE

Any ideas @CESARDELATORRE , btw? As mentioned above I've seen some conferences from you mentioning that topic.

Thank you very much.