▶ YouTube Summaries

• YT :: https://www.youtube.com/watch?v=8OGexAJs8Lc
• Original title :: When Microservices Actually Make Sense

Microservices are neither a scam nor a maturity badge - they are an expensive operating model. Before turning a codebase boundary into a network boundary, ask: what expensive coordination constraint gets cheaper? A service needs real independence in change, data, runtime and ownership; otherwise keep it in a modular monolith.

The independence tests

• Change :: can the team release without packaging, approving or rolling back another service? Coordinated releases and group-chat API changes mean "roommates with separate leases".
• Data :: who owns the source of truth? A shared database isn't evil, but multiple services writing the same tables and coordinating schema changes is where the coupling moved.
• Runtime :: if reporting or recommendations fail, does checkout still work? Timeouts, bounded retries, circuit breakers, queues, idempotency and fallbacks are the bill for crossing the network.
• Capacity :: where a service earns its keep - transcoding, search indexing, reporting, fraud scoring, image rendering have different resource curves than the critical path. Same traffic, cadence, storage and failure behaviour → splitting only adds dashboards.
• Ownership :: does one stable team own code, data, quality, contract, on-call and lifecycle? Moving folders to separate repos doesn't create autonomy.

Three reasons to pay the bill

• Different delivery cadence: a weekly-changing pricing engine shouldn't share a release train with a controlled billing ledger.
• Different failure/performance profiles: heavy reporting mustn't threaten checkout; recommendations can degrade, payment authorization can't.
• Durable domain ownership: a mature capability (identity, fulfilment, partner integration) run end to end by one team behind a stable contract.
• "We might scale one day" is not a reason - microservices charge interest now.

Boundary review

• Name the business capability and the expensive constraint, bring evidence, define the contract, declare one data owner, design the unhappy path, prove it can be operated.
• Extract one bounded thing, then measure: did lead time improve, blast radius shrink, operating load stay within limits? If not, stop multiplying services.
• A modular monolith is not an apology - it's where to build real seams while product and team boundaries still move. A service boundary is a promise of autonomy; if leadership won't fund the authority, platform work and on-call behind it, stay in the monolith and be honest about where the coupling lives.