All Articles


Sam Newman (2016), Building Microservices, O′Reilly.

The ideal integration technology

Whatever the technology we pick, let’s try to follow these rules:

  • Avoid breaking changes
  • Keep your APIs technology agnostic
  • Make your service simple for consumers
  • Hide internal implementation detail

Avoid shared databases

With database integration, we lose both strong cohesion and loose coupling. Our internal representation is exposed over the wire to our consumers, and it can be very difficult to avoid making breaking changes.

Synchronous vs. Asynchronous

With synchronous communication, a call is made to a remote server, which blocks until the operation completes. With asynchronous communication, the caller does not wait for the operation to complete before returning, may not even care whether or not the opration completes at all.

These two different modes of communication can enable two different idiomatic styles of collaboration: request/response or event-based. With request/response, a client initiates a request and waits for the response. With event-base collaboration, a client says “this thing happened” and expect other parties to know what to do.

Services as State Machines

Services are fashioned around bounded contexts. A service owns all logic associated with behavior in this context. Having the lifecycle of key domain concepts explicitly modeled like this is pretty powerful. Not only do we have one place to deal with collisions of state, but we also have place to attach behavior based on those state changes.

Dry and the Perils of Code Reuse in a Microservice World

DRY means the we want to avoid duplicating our system behavior and knowledge. Don’t violete DRY withing a microservice, but be relaxed about violating DRY across all services. One of the things we want to avoid at all costs is overly coupling a microservice and consumers such that any small change to the microservice itself can cause unnecessary to the consumer. Problems involved with too much coupling are far worse than the problems caused by code duplication.

Service versioning

  • Defer it for as long as possible: The best way to reduce the impact of making breaking changes is to avoid them in the first place.
  • Catch breaking change early
  • Use semantic versioning
  • Coexist with different endpoints while migrating

Think of user interfaces as compositional layers