Splitting an application.
WHAT THEY ARE
An application built as several small services, each independently deployable.
WHAT THEY PROMISE
Independent deployment Independent scaling Technology choice per service Team autonomy Failure isolation
WHAT THEY COST
Network calls where there were function calls Distributed failure modes Operational complexity Data consistency problems Difficult debugging
WHAT THAT MEANS
They trade a simple problem for several harder ones.
WHEN THEY ARE WARRANTED
Several teams needing to deploy independently Genuinely different scaling requirements Clear, stable boundaries between areas
WHEN THEY ARE NOT
Small teams Unclear boundaries Applications that are not yet large
WHAT TO START WITH
A well-structured single application, with clear internal boundaries.
WHY
Boundaries are discovered by building, and splitting on the wrong ones is far worse than not splitting.
WHAT TO EXTRACT FIRST, IF EXTRACTING
Something with a clear boundary and its own data.
WHAT NOT TO SPLIT
Anything requiring transactional consistency with the rest.
