Microservices asynchronous communication do handle inventory

Question

I'm building up an ecommerce app based on microservices and almost every article points out to use async communication. But I'm facing a situation that I think is better use sync communication. So, how control inventory using async communication?

Let's say I've a bus with 1k messages for decreasing the quantity of a product (and I've only 1k pieces of it), while not all messages are processed I still have those quantities and meanwhile another 500 orders are being placed, how handle that using bus service? I mean, this 500 orders should be refused...

Just for clarification, I'm starting with microservices.

Answer 1

You have not mentioned much details so I will answer based on assumptions.

If you can manage load with RDBMS (not having much load that can be handled without distributed system) then BEST TO USE mysql/oracle kind of RDBMS.

If you can manage this inventory transaction in a single microservice then we can think of using any sharded database like Mongo which will distribute writes in between multiple master nodes which is scalable.

But as you have mentioned you already have some message broker so you must be having multiple microservices involved in the transaction. In this case of distributed transaction we can use SAGA or 2PC or Shared-DB kind of patterns. In your case if you go with distributed transaction, user will see order status as IN PROGRESS after placing the order. And behind the scene distributed transaction will work based on Eventual Consistency. Later on status of order will be updated as per the transaction status. It is scalable but have added complexity.

Answer 2

The main question you have to answer is where you actually keep which data.

If you are in a situation, where you want to guarantee that the order you place is an order you can actually ship, you have to keep the quantity (or a reasonably accurate copy of the quantity) in your order service, not in the inventory service.

Then add something along the lines of a nightly inventory synchronization, maybe taking unprocessed orders into account, etc.

(And maybe then, overthink the merits of microservices alltogether and put this in a monolith, as everything gets much easier that way. Read Martin Fowler's take on microservices https://martinfowler.com/microservices/ esp. the part "Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.")

Answer 3

As I pointed out in a comment, you might need to get your requirements straight before you think about how to implement them. I.e. what needs to happen with the additional orders? Why not store them all as events and if nothing can be delivered a) trigger more production and send an email informing the customer of a delayed delivery giving them the option to cancel the order? or b) just directly send an email that the order cannot be fulfilled There is nothing in the information you provided that implies a need for synchronous communication? or ... there are many ways to deal with this problem on the process level. Clarify that first and then see what implementation matches best.

That being said all guidelines I know that praise async communication for microservices push it as a preferred way of communication where possible to increase decoupling and arguably scalability. But all I know go on to say that sync communication is fine if it matches your requirements better (enough don't even make a point about going async with events, to them it is just another variant). There is not the exact one way to do microservices, it is a relatively broad term.