Microservices Decomposition

If you're reading this skill instead of when-NOT-to-use-microservices, you've already justified the operational uplift. This skill is about HOW, not WHETHER. The wrong cuts produce distributed monoliths — same coupling, worse latency.

The opinion

Decompose by bounded context, not by entity. A "Users service" is wrong. An "Identity service" or a "Billing service" is right. Each service owns its data — no cross-service joins, no cross-service foreign keys. Communicate via async events for non-critical flows and HTTP for synchronous queries. Authenticate service-to-service with short-lived JWTs or mTLS. Never write a "shared models gem."

Step 1: Identify bounded contexts

A bounded context is a chunk of business capability with its own ubiquitous language. In an e-commerce monolith:

• Catalog — products, SKUs, categories, descriptions. Owned by content team.
• Inventory — stock levels, reservations, warehouse locations. Owned by ops.
• Orders — cart, checkout, fulfillment state. Owned by commerce.
• Billing — payment methods, invoices, refunds. Owned by finance.
• Identity — users, sessions, OAuth, 2FA. Owned by platform.
• Shipping — carriers, labels, tracking. Owned by logistics.