Two ways to structure a backend: one large codebase (monolith), or many small independent services (microservices).
Why it exists
A product can be built as one large program or as many small services, and the choice shapes how teams work, deploy, and fail. Monolith versus microservices exists as that architectural trade-off between one simple unit and many independently deployable ones.
How it actually works
A monolith keeps all the logic in one codebase and deploys as one unit. Simple to build and reason about early, but as it grows, every change risks the whole thing and teams step on each other.
Microservices split the system into small services (orders, payments, search), each owned and deployed independently. This scales teams and lets parts fail in isolation, at the cost of a lot more moving parts and network calls between services. Neither is universally right; it's a trade.
A senior PM walks you through it
A junior PM, stuck
I scoped scheduled delivery, letting customers pick a delivery time, as one ticket for one sprint. Engineering came back and turned it into five linked tickets across three teams. It looks like the estimate tripled overnight, and I am worried my lead will think I lowballed it or that eng is padding. I cannot tell which, because I do not understand why one feature became five tickets.
The five tickets are not scope creep and they are not padding, they are the shape of the architecture: the backend is split into independent services, and your one feature crosses several of them. Once you can read the epic, the split makes sense in about two minutes and you can defend the number. This is the actual epic engineering filed. Read it top to bottom, then take the steps with me.
Epic TIF-501: scheduled delivery
Parent and children
TIF-501 Scheduled delivery (customer picks a delivery time) [parent]
TIF-502 orders service: store and validate the chosen slot (Orders team)
TIF-503 orders service: return the slot in GET /api/orders (Orders team)
TIF-504 payments service: authorize now, capture at delivery time (Payments team)
TIF-505 notifications service: remind the customer before the slot (Notifications team)
TIF-506 orders service: schedule the dispatch job for the slot (Orders team)
Comment thread
Rafi: in the old monolith this was one PR.
Rafi: now each service owns its own piece and deploys on its own schedule, so it is one ticket per service plus the wiring between them.
Click a step to see the lines it points at.
Mistakes I've seen
Scoping a cross-cutting feature as one ticket in a microservices shop. Scheduled delivery touches orders, payments, and notifications, so one ticket was always going to fan out; asking which services it crosses first is what keeps your estimate honest.
Reading the fan-out as engineering padding or gold-plating. Each child maps to a service that has to change and deploy on its own, so five tickets is the architecture, not inflation, and calling it padding picks a needless fight.
Forgetting the coordination cost between services. The tickets are visible but the wiring between them is real work with no single owner, and features slip in that gap far more than in any one service's code.
Assuming the split means the work is bigger than it should be. A monolith would make this one PR but concentrate all the risk in one place; the trade is more tickets and coordination in exchange for teams and failures staying isolated, which is a choice, not a mistake to fix.
Tell your lead: "It is five tickets because scheduled delivery crosses three services, orders, payments, and notifications, each owned and deployed separately, plus the wiring between them. In a monolith it would have been one PR. I under-scoped it by treating it as one ticket, and here is the corrected estimate." You just read effort off the architecture instead of the feature description, which works on every cross-service scope you will write.
Where a PM meets this
It shapes how fast and safely teams ship. Microservices let teams move independently but make some features span many services and coordination.
"That change touches five services" versus "one codebase" predicts effort and risk; the architecture is context for your estimates.
Hear it in a meeting
"In the monolith this was one change; as microservices it's coordinating three teams."