An alt-SAGA Pattern for Microservices

The SAGA pattern is the recommended approach to achieving data consistency across microservices. There are many articles in dev.to and on the internet describing how SAGA handles distributed DB transactions. I'll therefore skip describing SAGA here. In this article I propose a pattern that I believe provides a simpler and cheaper alternative to the SAGA pattern.

Scenario

Consider two microservices

• OrderService and InventoryService
• when OrderService confirms successful payment it needs to notify the InventoryService to update its products table so the sold product is not listed in the products page.

An Alternative to the SAGA Pattern

For the alt-SAGA pattern I propose the following changes:

1. Configure all microservices with one additional common DB - the event sourcing table in addition to their native DB. (Yes, this deviates from the one DB per microservice pattern but I believe the benefits gained overweigh the deviation).
2. When a payment is successful, the OrderService updates its orders table and the event sourcing table.
3. Setup a cron service to call a sync API in InventoryService to update its products table, say, every 5 minutes (or whatevever interval suitable for the use case). This sync service updates the products table every 5 minutes if it sees any pending new entries in the event sourcing table.
4. If the InventoryService receives a GET request from the products page within this 5 minute interval then the sync is triggered first before responding to the GET request.
5. The above steps should keep the data in the orders table and the products table consistent.

Benefits

A major benefit I see in this pattern is the reduction in the complexity and cloud costs involved in adding a messaging service like Kafka between the microservices. Are there any teams out there already using such a pattern? I would love to get the readers' feedback on this approach.