Independent and Decentralized
Microservices Architecture takes modularity to its logical extreme. Instead of separate modules inside one codebase, you build separate, smaller applications that each run in their own process, on their own infrastructure, and are deployed completely independently.
Think of it like an apartment complex. Each tenant has their own fully self-contained apartment — their own kitchen, bathroom, and bedroom. They are independent. If one apartment has a plumbing leak, it does not flood the others. They communicate by knocking on doors or making phone calls (network requests). The building manager does not need to evacuate the whole building to fix one unit.
The Two Golden Rules
These are non-negotiable in a true microservices architecture. Violating either one collapses the benefits.
Rule 1 — Independent Deployment: You can build, test, and deploy the Payment Service without touching the Inventory Service. Each service has its own deployment pipeline. A team of three engineers can ship to production ten times a day without coordinating with five other teams.
Rule 2 — Decentralized Data: Each microservice owns its own database. The Order Service cannot connect directly to the Payment Service's database. If it needs payment data, it must ask the Payment Service via an API call. This is the hardest rule to follow and the most commonly violated one.
Sizing a Microservice
"Micro" is misleading. The right size for a service is not measured in lines of code — it is measured by the Single Responsibility Principle applied at the service level. A service should own one business capability. The Payment Service handles everything about payments. The Inventory Service handles everything about stock levels. A useful heuristic: if two services always need to be deployed together, they are probably one service. If one service needs to reach into another's database to do its job, the boundary is wrong.
The Trade-off
Pros: Teams can work and deploy independently. You can use different technology stacks per service (Python for ML-heavy services, Go for high-throughput services). You can scale only the services under load — scale the Search Service during peak traffic without scaling the Billing Service.
Cons: Massive operational complexity. You now manage 50 deployment pipelines instead of one. Network calls between services can fail, be slow, or return partial results. Data consistency across services requires careful design (you cannot use a database transaction across two services). Debugging requires distributed tracing across multiple services and log aggregation. This complexity is only worth it when team autonomy and independent scalability are genuine requirements.
A common interview question is: "What is the hardest part of microservices?" The answer interviewers want to hear is data consistency, not deployment. When a transaction spans multiple services (e.g., charge the card AND reserve inventory), you cannot use a database ACID transaction. You must use patterns like the Saga pattern or two-phase commit, both of which introduce significant complexity and failure modes. Mentioning this shows you understand the real operational cost, not just the marketing pitch.