Our reading notes

Microservices – Please, don’t

A cautionary account of the costs hidden behind promises of cleaner code and easier scaling through microservices.

The idea to take with you

You can improve modularity without creating a network boundary. Distribution adds failure and coordination problems of its own.

What to look for

  1. 01

    Separate a code-organization problem from an independent-deployment requirement.

  2. 02

    Account for cross-service transactions and partial failure.

  3. 03

    Understand the domain boundary before extracting a service.

Keep in mind

A 2015-era argument against unexamined enthusiasm, not proof that microservices are always a mistake. The argument concerns operational tradeoffs rather than a universal ban.

Put it to work

Try this next

For a proposed service extraction, name the owning team, data owner, failure modes, deployment benefit, and how the caller behaves during an outage.

Get the architecture template

Notes and exercises by Awesome CTO. The original work belongs to Sean Kelly.

Work through the bigger question.

Our architecture guide connects the reading to a practical approach and a template.

Open guide
Esc

Type to search every entry. ↑↓ to move, Enter to open.