2 comments


  • A Kumar

    I believe your points are very pertinent, and definitely do counter the ‘microservices death’ article you have referred to. I am indeed trying to understand the view points expressed in yours and the other article.

    I must confess that I wish you had posted a few examples – even at the cost of lengthening the article. A lengthy article when full of useful knowledge is simply a delight that goes on longer!

    Some specific questions:
    1) You say a service will generally not need to communicate with another service. I find this difficult to believe. For example, “generate bill” or “accept payment” service will need to look up a user’s various details, including subscriptions etc., which will almost always be another service call. AND this will possibly be across aggregates. For example, calculation of loyalty points may involve getting details across various business departments – and I believe these departments have a fairly good chance of mapping to what you call aggregates

    2) A direct call between services can often be replaced by a notification event. I do believe that the event based design promotes higher scalability – but at the cost of increased complexity, and possible splitting of a transaction into two or more transactions. For example, when a user purchases an item, his or her profile may or may not change depending on the $ amount of purchase. So item purchase and loyalty points change may be two different services, and they could communicate via notifications.
    Design options A and B:
    A) Create two services – item purchase, and loyalty adjustment. Both are separate transactions. In an ideal state, item-purchase would be immediately followed by loyalty adjustment. But to account for failure cases, a notification/pending-transactions table can be used to ensure that all the linked transactions are complete (via a batch job at the end of the night) . Now we have quite a few added complications caused by the event based design.
    B) Create 3 services – item purchase, loyalty adjustment, and item-purchase plus simultaneous loyalty adjustment. Now all the 3 services can avoid distributed transactions … depending upon the schema design. But now we have duplicated functionality in the 3rd service.

    What is your view on the above?

    April 30, 2019
    • Alexander Yermakov

      Hi Kumar,

      This is a vast subject and there are hundreds of books on this, so it’s not really viable to have a “somewhat longer article that explains it all clearly”, unfortunately.

      1. I speak of SOA Services / DDD Subdomains when I say there is hardly any need for point-to-point communication. However, there is always communication, but in most cases it follows notification style – eg. messaging in the form of “notification of what has happened” (aka Domain Event, aka SOA event). There are command messages as well – these carry an instruction to initiate an action.

      2. There is not enough context around “generate bill” or “accept payment” for me to comment on what form these can / should take. These may be commands or synchronous service invocations from UI initiated by a user.

      3. Departments won’t map to Aggregates. They *may* map to SOA Services / DDD Subdomains / DDD Bounded Contexts, but never to DDD Aggregates. DDD Aggregate is a transactional consistency boundary construct, and as such has very different purpose.

      4. Changes to a profile based on a purchase or loyalty points logic live is a completely different subdomain from the one that owns purchases. Eg. upon a successful purchase, a notification is emitted by the Sales SOA Service. This notification is handled by Profile Service and by Loyalty Program Service and these then take action based on their logic and received information about a purchase.

      5. Item Purchase and Loyalty Adjustments are *not* services. These are business processes.

      6. Nothing in real world require a successful purchasing transaction to be cancelled and rolled back if your loyalty program is unavailable at that moment. Think of your regular grocery store visit – you either get your points or are asked to stop by Customer Service desk to get those points credited to your account later. You are *not* denied to carry out your milk / bread.

      Another example. Amazon. You place your order, they take it. If they are out of stock all of a sudden (due to eventual consistency) – you get notified. Or they cancel the purchase after.

      7. You should *never* have distributed transactions for couple of reasons:
      – you will never make it fully work
      – DDD aggregate is your transactional consistency boundary – so the transaction completes within it and you are always sure about the outcome of that.

      May 01, 2019

Leave a reply to A Kumar Cancel Reply


This site uses Akismet to reduce spam. Learn how your comment data is processed.

Copyright © Alexander Yermakov