Eventual consistency, plainly

In the monolith, placing an order and deducting stock happened in the same database transaction. Both succeeded or both failed. Now that they live in different services, the stock is deducted milliseconds after the order is placed. For those milliseconds, the system is inconsistent. This is what eventual consistency means, plainly.

For most systems it is fine. Milliseconds of staleness rarely matter. For edge cases like inventory of the last item, you need a compensating action: when stock goes negative, the Inventory Service publishes OrderOversold and the Order Service reacts by cancelling one of the orders and refunding it. The cost of eventual consistency is that you have to design compensation flows for the edge cases. The benefit is that services stop blocking each other.