I am exploring using a microservice architecture. Among others, this would include three services, an Orders Service, a Products Service, and a Fulfillment Service.

Let's say the Fulfillment Service needs information about an order. What would be the more common and most accepted method for Fulfillment Service to access the order information?

  1. Fulfillment Service requests order data directly from Order Service via HTTP.

  2. Both Fulfillment Service and Order Service track copies of order data in their own databases. When orders are created, updated, or canceled, a message would be published which both services would listen for and handle.

    1. This might result in higher fault tolerance: if Order Service goes down, the Fulfillment Service can continue operating independently via its own copy of data.
    2. I suppose with this approach, you'd want to avoid allowing Fulfillment Service to modify product (each microservice would be the source of truth for its particular data).
  3. Another approach.

Some criteria:

  1. Avoid anti-patterns.
  2. Minimize coupling.
  3. Minimize complexity.
  • 1
    In order to answer the question "what is the most common approach," we would have to ask all of the companies who use micro services that talk to each other how they do it, and create a histogram of the techniques used. That's a pretty tall order. – Robert Harvey Nov 18 at 20:53
  • 1
    In order to answer the question "what is the most accepted method," you would additionally have to ask those companies why they made the choice they did. – Robert Harvey Nov 18 at 20:54
  • I'm just looking for what's the generally more accepted approach. I don't think we would have to ask every company out there. For example, if solution #1 is often more frowned upon in the general community, then that might leave us with solution #2. I just want to know peoples' general experience and gather insights. Not looking for a brick wall here. – Chad Johnson Nov 18 at 21:26
  • Your question would be a better one if you stated some criteria. In the absence of criteria, any technique will do. – Robert Harvey Nov 18 at 22:31
  • 3
    I recently joined a project where approach 1 is used. It doesn't make sense. I keep asking why we use microservices. Noone knows. The original developers are long gone. Boundaries are wrong resulting in many cross service requests. When this scales up it's gonna be a performance nightmare, which is kinda ironic because performance is probably one of the reasons the original developers decided to use microservices. Before deciding which approach to use, ask yourself: What problems do I hope to solve with microservices and are there perhaps other solutions with less complexity. – Rik D Nov 19 at 11:48

Both are viable. They have their tradeoffs.

First one is easier, but if Order service is down, so is Fullfilment service. It also becomes a problem with overall stability. If a service depends on 3 other services, and those have stability of 99.5%, then the service itself would have 0.995^3 = 0.985 = 98.5% . This might be unacceptable. And when you have dozens of services with many instances, these numbers quickly add up.

Second is more difficult, but Fullfilment service can work even when Order service is down. It also allows the Fullfilment service to store the data in a way that is easy for it to consume. This might not be true for whatever API the other services provide for it.

Third option is to use 'delayed' creation. In this scenario, the Fullfilment service tracks the state of it's request in persistent storage and starts it in 'is being fullfilled' state. Then, it sends asynchronous message to Order service, which Order service will process when it is up and ready. Once it is done, it will send response back to Fullfilment service, which will continue in the processing. This is different form of complication than keeping copy of the data, as you need to keep track of fullfilment state and revert it if something goes wrong (eg. with saga). And it requires client of Fullfilment service to know that it's request can be in 'to be finished' state. But it gives you advantage of high stability and no need to keep duplicate data.

| improve this answer | |
  • Thank you for a reasonable answer. I think this helps reinforce that the second option would probably be most suitable for my scenario. – Chad Johnson Nov 18 at 22:46

A slight alternative from second option is, Fullfilment service sends request messages in a queue so Order service can process them asynchronously. And both services share one append only event source table which is used for auditing, rollback, and recovery purpose. The event source table logs the request/process events at timestamps, so a materialized view of events could be used to track the orders regardless of the status of Order service.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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