In this article, it is mentioned (emphasis mine):

...the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.

My understanding is, if microservice 1 has build time dependency on microservice 2, then it is not microservice.

Considering microservice 1 & microservice 2, if the next version of microservice 2 has a new feature that is consumed by the next version of microservice 1, on specific HTTP API call, then what does microservice 1 being upgraded independently mean? Because the next version of microservice 1 has dependency (maven deploy(not build) dependency in Java) on the next version of microservice 2.

  • 1
    My understanding is, if microservice 1 has build time dependency(say using maven) on microservice 2, then it is not microservice. Commented Dec 25, 2019 at 19:07
  • It means that microservice 1 doesn't have any dependencies on microservice 2. "Independent" means exactly what you would think it means here. Commented Dec 25, 2019 at 19:37
  • @RobertHarvey you mean, microservice1 supposed to work irrespective of the version of microservice2 deployed? Otherwise microservice pattern is not a relevant design pattern for your requirement. Is that the understanding? Commented Dec 25, 2019 at 19:58
  • I was addressing the words "independently deployable." Commented Dec 25, 2019 at 20:04
  • microservice1 supposed to work irrespective of the version of microservice2 deployed? Moreover. Ms2 should not even care if Ms1 still exists.
    – Laiv
    Commented Dec 26, 2019 at 17:02

3 Answers 3


This characteristic is opposed to a monolith and means that you don't need to deploy two services sie-by-side.

In a case of a monolith, if you want to deploy a change in one part, you have to deploy the whole monolith. This means that you have essentially three problems:

  • Say you're ready to deploy your change, but the other team working on another part of the monolith is making a large change for one of the features, and their code cannot be deployed in its current state. Because of that, you cannot deploy your changes to production right now.

  • Any release then requires communication between the teams. Cross-team communication is exactly what microservices try to avoid.

  • The deployment of a monolith is rather complex. With higher complexity comes a higher risk of breaking something in production, which means that the team would be inclined to deploy less frequently.

In a case of independent services, you can deploy a single service right now, without communicating with other teams. They may be doing a large refactoring, or they may be deploying some changes to production themselves, or they may be on vacation for the next four weeks. You don't care about that, since your service is independently deployable.

Think of those services as being developed by different companies. For instance, you may use Amazon AWS. When Amazon releases a new feature, (1) it doesn't ask you a permission to do it, and (2) it doesn't force you to release the new version of your application at the same time as it does release the new feature. Amazon does the releases at its pace, and you do it at yours.

Note: this answer is based on Microservices by Eberhard Wolff. If you're interested in more details, you may be interested in reading the book.

  • You can deploy a single service right now... But what is the point in deploying it? When the new version of this microservice1 deployed is expecting new version of microservice2, otherwise microservice1 will fail on specific spot request Commented Dec 25, 2019 at 19:57
  • Amazon doesn't ask me because, we are just the consumers of the features provided by AWS. It is up to the consumer to use that newly added feature, by modify the consumer Commented Dec 25, 2019 at 20:03
  • 3
    You are missing the point. A consumer would have to wait for a new feature to be released anyway, microservices included: it doesn't make sense to expect to use a feature which is not available yet. The point is not to be able to deploy microservice1 early, but to be able to do it later than microservice2. With a monolith, you can't do it early or later, but necessarily at the same time. Commented Dec 25, 2019 at 20:30
  • When not to use microservice pattern? Commented Dec 25, 2019 at 21:01
  • 1
    @overexchange Can't speak to maven specifically. But, outside of maven, a dependency on a service is nearly-always going to be a runtime dependency -- not a build-time dependency. service-a should know how to talk to service-b and handle its outages gracefully; your build and deployment systems should not.
    – svidgen
    Commented Dec 26, 2019 at 18:15

Truly independent deployment means you can upgrade either service in any order and stay in a working state. Obviously, having no dependencies at all is ideal, but somewhat impractical. If you have dependencies between microservices, you can still deploy them independently:

In your example, microservice 2 can be upgraded at any time, provided it maintains backward compatibility.

Microservice 1 can also be upgraded at any time, provided it checks microservice 2 for compatibility and disables its new feature or falls back appropriately if its new dependencies aren't yet available.

That second method seems a little…unnecessary. Why not just save the hassle and upgrade microservice 2 first? I'll admit that's usually what I try to do, but there are a few unforeseen benefits of upgrading microservice 1 first.

First of all, it improves your error handling and troubleshooting later on if microservice 2 happens to have problems and needs to be rolled back. Second, it's often the clients that have a better idea what that new interface should look like. I've found that doing the clients first can sometimes minimize the back and forth of getting the interface right. Third, it allows deployment on test systems with a canned or prototype microservice 2, to get early feedback before committing too many resources to developing the new feature on microservice 2.

In other words, you're putting in extra effort in order to avoid getting into a situation where you have to flip a switch and upgrade every interdependent service at the same time. Those big-bang upgrades are fraught with risk.

  • We have another scenario, where, multiple business app microservices rely on a single util microservice through rest API. Util microservice has json and math functionality. How to handle dependencies on deploying new versions of util microservice? Commented Dec 26, 2019 at 18:12
  • 1
    Making its interface backward compatible. Or rolling out and running different versions of the same service and migrate progressively following the strangler pattern.
    – Laiv
    Commented Dec 26, 2019 at 18:39
  • For your point: "Microservice 1 can also be upgraded at any time, provided it checks microservice 2 for compatibility and disables its new feature or falls back appropriately if its new dependencies aren't yet available." Is it possible to disable new features and fall back, if its new dependencies aren't yet available? Can you share the example code? what is the design pattern? Commented May 25, 2020 at 23:01

To me, this is important because you can release changes in small batches and manage integration regressions much more easily.

With a monolith, you make a change to some feature area, build and deploy the entire thing and hope it goes well. With independent services, it's much easier to roll out small chunks and make sure they continue to play well.

Let's say you have Service A which handles something, and v1 is currently in production. All consumers use the v1 API. You introduce some updated functionality under a v2 API. You maintain backward compatibility on the v1 API and can 'silently' release the v2 API, and none of your consuming services need know or care. Service A is now supporting v1 and v2 APIs, and your other consumers can then start migrating to S1.v2 calls.

With complex monoliths, this is a very difficult and dangerous process, especially when you're running multiple different applications on a shared codebase in an enterprise setting. While microservices required considerably more discipline in many areas, it allows you to make your 'big system changes' in small pieces and without all of the external factors that make complex monolith updates a real bear.

We can somewhat liken it to refactoring code... when we refactor code, we tend to do so in small pieces at a time, check to make sure they work, then package it all up. I tend to find a practical use of microservices is similar, but on the component level instead: we can make small updates to various components without breaking anything, and when everything is surely working well, the old APIs and their implementations can be retired.

Aside from the oft-touted advantages of requiring no outside knowledge, the service team completely owning the service, no cross-service dependencies, etc., this ability to do complex releases in small stages due to the independence is a significant practical advantage of working with microservice architectures.

  • But what about the challenge in design ing the complete requirement as set of microservice s? What should be the approach? Can every requirement in the world be given a microservice solution? What are the factors that decide to go for microservice approach? stackoverflow.com/a/46680273/3317808 Commented Dec 26, 2019 at 15:53
  • So, How to answer the question, should that be a microservice? What are the reasons to not use microservice? For any given requirement Commented Dec 26, 2019 at 16:00
  • That's a very broad topic. Microservices have a great fit in many places, but tend to work by spreading the complexity of a monolith to the service communications and configuration instead. There's entire books written on the subject (the one by Sam Newman would be my recommendation, but I don't have the ISBN handy as I'm on holiday). When and why to use microservices are big questions for sure. And often times (especially with an existing monolith), a hybrid solution is the most practical choice: not "full on" services, but at least break the mono into a handful of components, etc.
    – jleach
    Commented Dec 26, 2019 at 20:27

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.