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.

  • 4
    I mean, this 500 orders should be refused I advise you to really really really talk to your business stakeholders before making decisions like that.
    – Rik D
    Commented Jan 18, 2021 at 14:55
  • 1
    Assume the business has two sales people talking on the phone to a client and they both sell the same 500 products at the same time. How do they handle that situation?
    – Rik D
    Commented Jan 18, 2021 at 14:58
  • That's my question Rik D. Commented Jan 18, 2021 at 15:25
  • 2
    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. That being said, I'm not sure I see a question for us here - it seems it is your requirements that need clarification. Could the additional orders not trigger additional production of the product? Commented Jan 19, 2021 at 5:45

3 Answers 3


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.

  • Interesting answer. I'll take a good read on topics you mentioned. Commented Jan 19, 2021 at 10:57

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.

  • Helpful thought. I'll refine the requirements. Not marked as answer but took good points on the question. Commented Jan 19, 2021 at 11:05

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.")

  • I like the idea to keep inventory in order service. But as you mentioned Martin Fowler's maybe I need to dig up a bit more. Anyway, although I did not mark you answer as answered, it brought some light to question. Commented Jan 19, 2021 at 11:02
  • 1
    I love how a lot of people know the Fowler quote and even agree with it and then still go on to decide that it doesn't apply to them. So they proceed and start building microservices from scratch because they believe they'll scale to amazon levels in the first year. I guess it is part of being a programmer to overestimate one's self Commented Jan 25, 2021 at 14:09
  • @Bjorn De Rijcke I guess, that is the difference between a programmer's view and an architect's view. As a programmer, I'd love to try myself in the challenge of microservices, as an architect, I'd be nuts to even try this.
    – mtj
    Commented Jan 25, 2021 at 17:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.