I am new to microservice.
While learning about them, I was wondering what is the basic rules (the minimum) that make a microservice a microservice.

I have found some rules/characteristics along the way:

  • Loose-coupling, independent and scalable web services.
  • Doesn't have to be the same technologies, but must agreed on a common protocol (HTTP, TCP...) and message format (JSON, protobuf...), at least inside a business domain it self.
  • Containerized.
  • Have healthchecks.
  • Use message broker (RabbitMQ, Kafka) & Event-driven architecture.
  • Use Gateways, Service Discoveries, Load Balancers (or a combination of those three: Reverse Proxy).
  • Use of DDD and CQRS patterns.
  • Use microservice patterns.

Am I missing something else? How was microservice normally be designed and developed in different companies?

  • I suspect it won't be properly answerable; what is the boundary for "micro" in "microservice" as opposed to a "service"?
    – pjc50
    Commented Mar 2, 2023 at 11:15
  • 2
    I think an important point is a microservice is something developed by its own separate team. If you have one team that writes all the microservices, you're just LARPing. Commented Mar 2, 2023 at 11:57
  • @user253751 In practice, I think this often true and it's a key driver of the approach but it's not literally correct. A single team could maintain multiple microservices and you can have multiple teams work on different parts of a monolith. What you are describing is the organizational advantage that makes this an appealing technical approach.
    – JimmyJames
    Commented Mar 2, 2023 at 17:08

2 Answers 2


I do not think you will get a definite list of rules that everyone will agree on. The main reason is that there will always be someone who calls their solution for "microservices", or whatever other pattern is fashionable, while violating most of the ideas behind the pattern.

Wikipedia seem to agree with me:

There is no single definition for microservices. A consensus view has evolved over time in the industry. Some of the defining characteristics that are frequently cited include:

  • Services in a microservice architecture are often processes that communicate over a network to fulfill a goal using technology-agnostic protocols such as HTTP.
  • Services are organized around business capabilities.
  • Services can be implemented using different programming languages, databases, hardware and software environments, depending on what fits best.
  • Services are small in size, messaging-enabled, bounded by contexts, autonomously developed, independently deployable, decentralized and built and released with automated processes.

In my opinion, microservices is as much, or more, of an organizational pattern as it is a technology pattern. One of the core ideas is that it should make development teams more independent from each other. Most of the technologies derive from this requirement:

  1. Services must be loosely coupled, since the teams that develop each service are independent.
  2. They should use a common communication protocol, since this is the interface between services, and you don't want your developers to have to learn to many different protocols.
  3. Most technology choices can be moved to each team, avoiding compromises and infighting. Still, some commonality might be beneficial since developers might move between teams.
  4. You need good tools to deploy your software, since some of the complexity have been moved to the deployment step.

While you probably can follow the pattern even if you are a single team, I think it will require extraordinary discipline. If you are responsible for multiple services I suspect there is a great temptation to introduce dependencies between services. But I have not really worked on any large scale microservice system, so I cannot claim to be an expert.


While I agree that the term 'microservices' has become subjective and used to describe many different approaches, if you are looking for a definition that is useful for building robust systems, I think there's one core principle of the approach that captures almost all of the value: autonomy.

Service autonomy effectively means that you are able to deploy implementation changes to the service without having to worry about how those changes impact any other solution. For example, you can completely rework the design of your database and deploy a new version of your solution without coordinating with any other team or solution implementation.

A common corruption of this idea is that you can implement microservices simply by deploying every endpoint as a separate instance (e.g.: containers). The thing is that if all these deployments are sharing the same database, then they aren't autonomous. This isn't to say that there's no advantage to using containers in this way, it's just not a 'microservice' architecture. The term is confusing in this way, because it implies 'tiny services' and what would be tinier than one container per endpoint? It's a somewhat unfortunate term IMO.

I think a really decent rule-of-thumb is that you can't have more microservices than databases. Or, in other words, you can't have two (or more) microservices that use the same DB. If you have multiple endpoints and/or operations that share a DB, they are part of the same microservice (or part of a monolith.) You can sort of get close by using strictly separated schemas in the same DB but conceptually, it's the same idea: the ability to change implementation independently. Obviously not all services necessarily need a persistent datastore so this isn't universal but for most developers and architects getting started with this idea, I think it will help you focus on the important benefit of this idea: increased flexibility and reduced complexity at an architectural level. That's why this approach is so common in large organizations. It eliminates a lot of the need for large-scale coordination between teams and allows each team to move faster.

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