Start With a Monolith, Not a Distributed Mess
I've seen too many teams jump straight into microservices because it sounds modern. The result is usually a distributed monolith: all the pain of network calls, none of the benefits. Start with a well-structured monolith. Draw clear module boundaries, enforce them with package structure, and only extract services when you have concrete scaling or team reasons.
Pitfall 1: Over-Splitting by Technical Layers
Splitting services by layer (UI, business logic, data) is a trap. Each service ends up calling the next in a chain, turning every user request into a waterfall of network hops. Instead, split by business capability. Think "orders," "payments," "inventory," not "frontend," "backend," "database."
Pitfall 2: Ignoring Data Ownership
