Microservices Architecture: Benefits & Trade-offs

TL;DR

Microservices architecture decomposes applications into independently deployable services, each owning a specific business capability with its own data store and technology stack. This pattern enables teams to scale, deploy, and evolve services independently, but introduces significant operational complexity through distributed system challenges like network failures, data consistency, and service orchestration. The key decision isn’t whether microservices are “better” than monoliths—it’s whether your organization can handle the operational overhead in exchange for deployment independence and team autonomy.

Cheat Sheet: Bounded contexts define service boundaries | Database per service ensures independence | Service mesh handles cross-cutting concerns | Conway’s Law: team structure mirrors architecture | Start monolith-first unless you have strong organizational reasons

The Problem It Solves

Traditional monolithic applications create organizational bottlenecks as they scale. When Netflix had a single monolithic application serving streaming video, every feature change required coordinating across teams, deploying the entire application, and risking system-wide outages from a single bug. A database deadlock in the recommendation engine could crash the entire platform. Teams couldn’t choose the best technology for their specific problem—everyone was locked into the same language, framework, and database. Scaling meant replicating the entire monolith, even if only the search service needed more capacity.

The deeper problem is coupling—both technical and organizational. In a monolith, shared code creates implicit dependencies. The billing team can’t deploy independently because their code shares a database schema with the user profile team. A change to a shared utility class requires regression testing the entire application. As the codebase grows, build times stretch to 30+ minutes, and deployment windows require coordinating dozens of teams. The blast radius of any failure is the entire system.

This coupling extends to teams. When everyone works in the same codebase, you need extensive coordination, code review bottlenecks, and merge conflicts. High-performing engineers get blocked waiting for other teams. The organization can’t scale beyond a certain size because communication overhead grows quadratically with team count. You need a way to let teams move independently while still building a cohesive product.

Monolith Coupling: Shared Database Creates Deployment Dependencies

graph TB
    subgraph Monolithic Application
        BillingCode["Billing Module"]
        ProfileCode["User Profile Module"]
        OrderCode["Order Module"]
        SharedLib["Shared Utility Library"]
        
        BillingCode -."imports".-> SharedLib
        ProfileCode -."imports".-> SharedLib
        OrderCode -."imports".-> SharedLib
    end
    
    SharedDB[("Shared Database<br/>users, orders, billing")]
    
    BillingCode --"direct SQL queries"--> SharedDB
    ProfileCode --"direct SQL queries"--> SharedDB
    OrderCode --"direct SQL queries"--> SharedDB
    
    Deploy["Single Deployment Unit<br/>⚠️ All teams must coordinate<br/>⚠️ 30+ min build time<br/>⚠️ System-wide blast radius"]
    
    BillingCode --> Deploy
    ProfileCode --> Deploy
    OrderCode --> Deploy
    SharedLib --> Deploy

In a monolith, shared database and code create tight coupling. A schema change in the billing module requires coordinating deployment with profile and order teams, even if they haven’t changed their code. The blast radius of any bug is the entire system.

Solution Overview

Microservices architecture solves this by decomposing the application into small, independently deployable services organized around business capabilities. Each service is owned by a single team, has its own database, and communicates with other services through well-defined APIs. The user profile service, recommendation engine, video transcoding service, and billing service all run as separate processes, deployed independently, potentially written in different languages.

The key insight is that organizational independence requires technical independence. If services share a database, they can’t deploy independently—a schema change requires coordinating deployments. If they share code libraries, a dependency update requires synchronized releases. Microservices enforce boundaries that enable team autonomy.

This isn’t just splitting code into modules. It’s a fundamental shift in how you think about system boundaries. Instead of organizing code by technical layers (controllers, services, repositories), you organize by business domains. The “order” microservice owns everything related to orders—the API, business logic, database schema, and background jobs. This aligns with Domain-Driven Design principles, where each service represents a bounded context with its own ubiquitous language.

The architecture introduces new components to manage the distributed nature: API gateways route external requests, service meshes handle inter-service communication, and distributed tracing tracks requests across service boundaries. You trade the simplicity of in-process function calls for the flexibility of independent deployment and scaling.

Microservices Architecture: Independent Services with Owned Data

graph LR
    Client["Client Application"]
    Gateway["API Gateway"]
    
    subgraph User Service Team
        UserAPI["User Service<br/><i>Node.js</i>"]
        UserDB[("User DB<br/>PostgreSQL")]
    end
    
    subgraph Order Service Team
        OrderAPI["Order Service<br/><i>Java</i>"]
        OrderDB[("Order DB<br/>MongoDB")]
    end
    
    subgraph Payment Service Team
        PaymentAPI["Payment Service<br/><i>Go</i>"]
        PaymentDB[("Payment DB<br/>PostgreSQL")]
    end
    
    subgraph Notification Service Team
        NotificationAPI["Notification Service<br/><i>Python</i>"]
        Queue["Message Queue<br/><i>Kafka</i>"]
    end
    
    Client --"1. HTTPS"--> Gateway
    Gateway --"2. Route request"--> UserAPI
    Gateway --"3. Route request"--> OrderAPI
    Gateway --"4. Route request"--> PaymentAPI
    
    UserAPI --"owns"--> UserDB
    OrderAPI --"owns"--> OrderDB
    PaymentAPI --"owns"--> PaymentDB
    
    OrderAPI --"5. Publish event"--> Queue
    PaymentAPI --"6. Publish event"--> Queue
    Queue --"7. Subscribe"--> NotificationAPI

Each microservice is independently deployable, owns its database exclusively, and can use different technology stacks. Services communicate through APIs (synchronous) or events (asynchronous), enabling teams to work autonomously.

How It Works

Step 1: Identify Bounded Contexts. Start with domain-driven design to find natural service boundaries. At Uber, the core domains are riders, drivers, trips, payments, and routing. Each represents a distinct business capability with its own data model and rules. A “trip” has a different meaning in the routing context (a sequence of GPS coordinates) versus the billing context (a transaction with surge pricing). These different perspectives indicate separate bounded contexts.

The key question is: “Can this capability change independently?” If the payment processing rules can evolve without affecting how trips are matched to drivers, they belong in separate services. Look for areas where different teams naturally own different parts of the business logic.

Step 2: Define Service Boundaries and APIs. Each service exposes a contract—typically a REST API, gRPC interface, or event schema. The Trip Service might expose POST /trips to create a trip, GET /trips/{id} to retrieve details, and publish TripCompleted events when a ride finishes. These contracts are versioned and backward-compatible to prevent breaking changes from cascading across services.

Critically, services own their data exclusively. The Trip Service has a trips database that no other service can access directly. If the Payment Service needs trip details, it calls the Trip Service API or subscribes to trip events. This prevents the tight coupling that plagued monoliths, where any team could write a SQL query joining across domain boundaries.

Step 3: Implement Inter-Service Communication. Services communicate through two primary patterns: synchronous request-response (REST/gRPC) and asynchronous messaging (events/message queues). When a user requests a trip, the API Gateway forwards the request to the Trip Service, which synchronously calls the Routing Service to calculate the route and the Pricing Service to estimate the fare. These are blocking calls—the Trip Service waits for responses.

For workflows that don’t need immediate responses, services publish events. When a trip completes, the Trip Service publishes a TripCompleted event. The Payment Service subscribes to charge the rider, the Analytics Service updates metrics, and the Notification Service sends a receipt—all asynchronously. See Event-Driven Architecture for detailed patterns on handling distributed transactions and eventual consistency.

Step 4: Deploy and Scale Independently. Each service runs in its own container or VM, with its own deployment pipeline. The Routing Service can deploy 10 times per day while the Payment Service deploys weekly. If the Routing Service needs more capacity during rush hour, you scale just that service—not the entire application. This is where microservices deliver real value: deployment independence and granular scaling.

Netflix deploys services hundreds of times per day. A change to the recommendation algorithm doesn’t require redeploying the video player, billing system, or user authentication. The blast radius of a bad deployment is limited to a single service, and rollbacks are fast.

Step 5: Manage Cross-Cutting Concerns with Service Mesh. As the number of services grows, cross-cutting concerns like authentication, rate limiting, circuit breaking, and observability become challenging. Rather than implementing these in every service, a service mesh like Istio or Linkerd deploys a sidecar proxy alongside each service instance. The sidecar intercepts all network traffic, handling retries, timeouts, mutual TLS, and distributed tracing transparently.

This is a key architectural component that makes microservices operationally viable at scale. Without a service mesh, you’d need to implement retry logic, circuit breakers, and observability in every service, in every language. The mesh centralizes these concerns while maintaining service independence.

Inter-Service Communication: Synchronous vs Asynchronous Patterns

sequenceDiagram
    participant Client
    participant Gateway as API Gateway
    participant Trip as Trip Service
    participant Route as Routing Service
    participant Price as Pricing Service
    participant Queue as Event Bus<br/>(Kafka)
    participant Payment as Payment Service
    participant Analytics as Analytics Service
    
    Note over Client,Price: Synchronous Request-Response Flow
    Client->>Gateway: 1. POST /trips/request
    Gateway->>Trip: 2. Create trip
    Trip->>Route: 3. GET /route/calculate<br/>(blocking call)
    Route-->>Trip: 4. Route data
    Trip->>Price: 5. GET /price/estimate<br/>(blocking call)
    Price-->>Trip: 6. Price estimate
    Trip-->>Gateway: 7. Trip created (200 OK)
    Gateway-->>Client: 8. Response
    
    Note over Trip,Analytics: Asynchronous Event-Driven Flow
    Trip->>Queue: 9. Publish TripCompleted event<br/>(non-blocking)
    Trip-->>Gateway: 10. Return immediately
    Queue->>Payment: 11. Consume event<br/>(async)
    Queue->>Analytics: 12. Consume event<br/>(async)
    Payment->>Payment: Process payment
    Analytics->>Analytics: Update metrics

Synchronous calls (REST/gRPC) block until response is received, compounding latency but providing immediate results. Asynchronous events decouple services—the Trip Service doesn’t wait for payment processing or analytics updates, improving resilience and performance.

Service Mesh Architecture: Sidecar Pattern for Cross-Cutting Concerns

graph TB
    subgraph Service A Pod
        AppA["Application A<br/><i>Business Logic</i>"]
        ProxyA["Envoy Sidecar<br/><i>Service Mesh Proxy</i>"]
    end
    
    subgraph Service B Pod
        AppB["Application B<br/><i>Business Logic</i>"]
        ProxyB["Envoy Sidecar<br/><i>Service Mesh Proxy</i>"]
    end
    
    subgraph Service C Pod
        AppC["Application C<br/><i>Business Logic</i>"]
        ProxyC["Envoy Sidecar<br/><i>Service Mesh Proxy</i>"]
    end
    
    ControlPlane["Service Mesh Control Plane<br/><i>Istio/Linkerd</i><br/>• Traffic policies<br/>• mTLS certificates<br/>• Telemetry config"]
    
    AppA <--"localhost"--> ProxyA
    AppB <--"localhost"--> ProxyB
    AppC <--"localhost"--> ProxyC
    
    ProxyA --"1. Request with mTLS<br/>+ retry logic<br/>+ circuit breaker"--> ProxyB
    ProxyB --"2. Request with mTLS<br/>+ load balancing<br/>+ timeout"--> ProxyC
    
    ControlPlane -."Configure policies".-> ProxyA
    ControlPlane -."Configure policies".-> ProxyB
    ControlPlane -."Configure policies".-> ProxyC
    
    ProxyA & ProxyB & ProxyC -."Send telemetry<br/>(traces, metrics)".-> ControlPlane

Service mesh deploys a sidecar proxy alongside each service instance. The proxy intercepts all network traffic, transparently handling retries, circuit breaking, mutual TLS, load balancing, and distributed tracing—without requiring changes to application code.

Variants

1. Domain-Oriented Microservices: Services organized strictly around business domains (orders, inventory, shipping). Each service owns a complete vertical slice—API, business logic, database, and UI components if applicable. This is the canonical microservices pattern, emphasizing bounded contexts and domain-driven design. Use this when you have clear domain boundaries and want maximum team autonomy. The trade-off is potential duplication of infrastructure code across services.

2. Backend-for-Frontend (BFF): Each client type (web, iOS, Android) gets a dedicated backend service that aggregates data from domain services and formats responses optimally for that client. Spotify uses this pattern—the iOS app calls a different backend than the web player, even though both ultimately fetch data from the same underlying services. Use this when different clients have significantly different data needs and you want to avoid bloating domain services with client-specific logic. The trade-off is maintaining multiple BFF services.

3. Micro-Frontends: Extends microservices to the frontend, where each team owns both the backend service and the UI components for their domain. The order team owns the checkout UI, the product team owns the catalog UI, and they’re composed into a single application. Use this for large organizations where you want true end-to-end ownership. The trade-off is complexity in frontend composition and ensuring a consistent user experience.

4. Modular Monolith: A middle ground where the application is a single deployable unit, but internally organized into well-defined modules with strict boundaries. Shopify uses this pattern—modules communicate through defined interfaces and can’t access each other’s databases directly, but everything deploys together. Use this when you want the organizational benefits of bounded contexts without the operational complexity of distributed systems. You can later extract modules into true microservices if needed. The trade-off is you don’t get independent deployment or scaling.

Trade-offs

Deployment Independence vs Operational Complexity: Microservices let you deploy the recommendation service without touching the payment service, enabling faster iteration and reducing blast radius. However, you now manage dozens or hundreds of services, each with its own deployment pipeline, monitoring, logging, and alerting. You need container orchestration (Kubernetes), service discovery, distributed tracing, and sophisticated deployment strategies like canary releases. A monolith has one deployment pipeline and one monitoring dashboard. Choose microservices when deployment independence is worth the operational overhead—typically when you have multiple teams that need to move independently.

Granular Scaling vs Resource Overhead: In a monolith, scaling the search feature means replicating the entire application, including the rarely-used admin panel. Microservices let you scale just the search service, optimizing resource usage. However, each service has baseline overhead—memory for the runtime, CPU for health checks, network for inter-service communication. Running 50 microservices might consume more total resources than one monolith due to this overhead. Choose microservices when different components have significantly different scaling characteristics (e.g., read-heavy search vs write-heavy billing).

Technology Flexibility vs Ecosystem Fragmentation: Microservices let each team choose the best tool for their problem. The search team uses Elasticsearch and Python, the real-time notification team uses Go and WebSockets, the analytics team uses Spark and Scala. This flexibility is powerful but creates fragmentation—multiple languages to hire for, multiple frameworks to maintain, multiple security vulnerabilities to patch. A monolith enforces consistency. Choose microservices when the benefits of specialized technology outweigh the cost of maintaining a heterogeneous ecosystem.

Fault Isolation vs Distributed System Failures: When the recommendation service crashes in a microservices architecture, the rest of the system continues functioning (with degraded recommendations). In a monolith, a crash takes down everything. However, microservices introduce network failures, partial failures, and cascading failures. The payment service might be healthy, but if the network is congested, requests timeout. You need circuit breakers, retries with exponential backoff, and bulkheads to prevent cascading failures. Choose microservices when fault isolation is critical and you can invest in resilience patterns.

Data Consistency vs Query Complexity: Each microservice owns its database, ensuring no shared state. But now, generating a report that joins orders, inventory, and shipping data requires calling three services and joining in memory, or implementing eventual consistency through events. In a monolith, it’s a single SQL join. Distributed transactions are complex—you typically use the saga pattern for cross-service workflows. Choose microservices when the benefits of data ownership outweigh the complexity of distributed data management.

Common Anti-Patterns

Distributed Monolith: You’ve split the codebase into multiple services, but they’re tightly coupled through synchronous calls and shared databases. Every deployment still requires coordinating across services because they can’t function independently. This is the worst of both worlds—monolith coupling with microservices complexity. It happens when you decompose by technical layers instead of business domains, or when you don’t enforce database-per-service. Avoid this by ensuring each service can function (perhaps with degraded features) even if other services are down, and by using asynchronous communication where possible.

Chatty Services: The order service calls the inventory service, which calls the pricing service, which calls the discount service—a single user action triggers a cascade of synchronous network calls. Latency compounds (100ms per call × 5 calls = 500ms), and failure probability multiplies. This happens when service boundaries are too fine-grained or when you decompose without considering data access patterns. Avoid this by designing services around business transactions (an “order” service that owns pricing and inventory checks), using API composition at the gateway layer, or caching frequently accessed data.

Shared Database: Multiple services read and write to the same database tables, creating tight coupling. A schema change requires coordinating deployments across services, defeating the purpose of microservices. This happens when teams prioritize short-term convenience (“it’s easier to just query the orders table directly”) over long-term independence. Avoid this by strictly enforcing database-per-service and providing APIs or events for data access. If you must share data, use read replicas or materialized views that services own.

Premature Decomposition: You start with microservices on day one, before understanding domain boundaries. Services are split incorrectly, requiring constant refactoring and data migration. You spend more time managing infrastructure than building features. This happens when teams adopt microservices for resume-driven development or because “that’s what Netflix does.” Avoid this by starting with a modular monolith, identifying bounded contexts through real usage patterns, and extracting services only when you have organizational reasons (multiple teams, different scaling needs). Amazon’s rule: you need at least two teams before microservices make sense.

Lack of Service Ownership: Services are created but no team owns them end-to-end. When the payment service has issues, it’s unclear who’s responsible. Deployments require cross-team coordination. This happens when you decompose technically (“the API team” vs “the database team”) instead of by business domain. Avoid this by aligning services with team structure (Conway’s Law)—each team owns one or more complete services, including development, deployment, and on-call support.

Distributed Monolith Anti-Pattern: Tight Coupling with Microservices Complexity

graph LR
    subgraph Distributed Monolith - Worst of Both Worlds
        UI["UI Service"]
        Order["Order Service"]
        Inventory["Inventory Service"]
        Price["Pricing Service"]
        SharedDB[("❌ Shared Database<br/>All services access")]
        
        UI --"Synchronous call<br/>⚠️ Blocking"--> Order
        Order --"Synchronous call<br/>⚠️ Blocking"--> Inventory
        Inventory --"Synchronous call<br/>⚠️ Blocking"--> Price
        
        Order -."❌ Direct SQL".-> SharedDB
        Inventory -."❌ Direct SQL".-> SharedDB
        Price -."❌ Direct SQL".-> SharedDB
    end
    
    Problems["Problems:<br/>• Can't deploy independently<br/>• Schema changes require coordination<br/>• Cascading failures (5 hops)<br/>• Latency compounds (500ms+)<br/>• Microservices complexity<br/>• Monolith coupling"]
    
    SharedDB -.-> Problems
    UI -.-> Problems

The distributed monolith anti-pattern combines the worst aspects of both architectures: services are split but tightly coupled through shared databases and synchronous call chains. You get microservices operational complexity without deployment independence or fault isolation.

When to Use (and When Not To)

Use microservices when: (1) You have multiple teams (3+) that need to deploy independently without coordination. A single team can manage a modular monolith more efficiently. (2) Different parts of your system have significantly different scaling characteristics—your video transcoding service needs GPU instances while your API needs CPU-optimized instances. (3) You need technology diversity for legitimate reasons—real-time services benefit from Go’s concurrency while data pipelines benefit from Python’s ecosystem. (4) You have the operational maturity to run distributed systems—experienced SREs, container orchestration, comprehensive monitoring, and on-call rotations. (5) Your organization can align teams with service boundaries (Conway’s Law)—each team owns a service end-to-end.

Don’t use microservices when: (1) You’re a startup finding product-market fit. The overhead of managing distributed systems will slow you down when you need to pivot quickly. (2) You have a small team (< 10 engineers). The operational complexity isn’t worth it. (3) Your domain boundaries are unclear. You’ll spend more time refactoring service boundaries than building features. (4) You don’t have strong DevOps practices. Microservices require mature CI/CD, monitoring, and incident response. (5) Your system is primarily CRUD operations with simple business logic. A well-structured monolith will be faster to develop and operate.

Red flags: Choosing microservices because “it’s what big companies do” without understanding why. Decomposing before you understand domain boundaries. Expecting microservices to solve organizational problems (poor communication, unclear ownership). Underestimating the operational complexity—distributed tracing, service mesh, container orchestration, and managing dozens of deployment pipelines require significant investment.

Real-World Examples

Netflix: Operates 700+ microservices handling 200+ million subscribers. Each service owns a specific capability—user profiles, recommendations, video encoding, CDN routing, billing. Services are written in Java, Node.js, Python, and Go depending on the use case. They deploy thousands of times per day using Spinnaker for continuous delivery. The interesting detail: Netflix built Hystrix (circuit breaker library) and Eureka (service discovery) because existing tools couldn’t handle their scale. They learned that microservices require significant investment in infrastructure tooling. Their chaos engineering practice (Chaos Monkey) deliberately kills services in production to ensure the system is resilient to failures—a necessity when you have hundreds of services.

Uber: Migrated from a monolithic Python application to 2,200+ microservices. Core services include trip management, routing, pricing, payments, and driver dispatch. Each city operates semi-independently with its own service instances to comply with local regulations. Services communicate through both REST APIs and Apache Kafka for event streaming. The interesting detail: Uber built their own service mesh (not using Istio/Linkerd) because they needed custom routing logic for multi-region deployments and regulatory compliance. They also developed Jaeger for distributed tracing because existing tools couldn’t handle their request volume. The migration took years and required building extensive tooling—it wasn’t just splitting code, but fundamentally changing how teams work.

Amazon: Pioneered microservices in the early 2000s with their famous mandate: all teams must expose functionality through service interfaces, no direct database access allowed. The retail website is composed of hundreds of services—product catalog, recommendations, cart, checkout, inventory, shipping. Each service is owned by a “two-pizza team” (small enough to feed with two pizzas). The interesting detail: Amazon’s microservices adoption was driven by organizational scaling, not technical requirements. As they grew beyond 500 engineers, coordination overhead made the monolith unmanageable. The architecture change enabled organizational scaling—they now have thousands of engineers working independently.

---

Interview Essentials

Mid-Level

Explain the difference between monolithic and microservices architectures with concrete examples. Describe how services communicate (REST, gRPC, message queues) and the trade-offs of synchronous vs asynchronous communication. Discuss the database-per-service pattern and why shared databases create coupling. Explain basic resilience patterns like timeouts and retries. Be able to identify when a system should NOT use microservices—startups, small teams, unclear domain boundaries. Demonstrate understanding that microservices solve organizational problems (team independence) more than technical problems.

Senior

Design service boundaries using domain-driven design principles—identify bounded contexts and explain why certain capabilities belong together. Discuss data consistency challenges and solutions (eventual consistency, saga pattern, event sourcing). Explain how to handle distributed transactions without two-phase commit. Describe service mesh architecture and what problems it solves (observability, security, traffic management). Analyze the operational complexity trade-offs—when is the overhead worth it? Discuss deployment strategies (blue-green, canary) and how to safely roll out changes across dependent services. Explain how to prevent cascading failures with circuit breakers and bulkheads.

Staff+

Architect a migration path from monolith to microservices—which services to extract first, how to handle shared data during migration, organizational changes required. Discuss Conway’s Law and how to align team structure with architecture. Design cross-cutting concerns at scale—authentication, authorization, rate limiting, observability across hundreds of services. Evaluate build vs buy decisions for service mesh, API gateway, and observability platforms. Discuss the economics of microservices—when does the operational overhead outweigh benefits? Design for multi-region deployments with regulatory constraints (data residency, compliance). Explain how to maintain system-wide SLAs when reliability is the product of individual service SLAs.

Common Interview Questions

When would you choose microservices over a monolith? (Focus on organizational factors—team size, deployment independence—not just technical factors)

How do you handle distributed transactions across microservices? (Saga pattern, eventual consistency, compensating transactions)

How do you prevent cascading failures in a microservices architecture? (Circuit breakers, bulkheads, timeouts, graceful degradation)

How do you maintain data consistency when each service has its own database? (Event sourcing, CQRS, eventual consistency, idempotency)

How do you handle service discovery and load balancing? (Cross-reference to service discovery topic, but mention client-side vs server-side discovery)

What’s your strategy for API versioning across services? (Backward compatibility, semantic versioning, deprecation policies)

How do you debug a request that spans 10 services? (Distributed tracing with correlation IDs, centralized logging, observability platforms)

Red Flags to Avoid

Claiming microservices are always better than monoliths without discussing trade-offs

Not understanding the operational complexity—monitoring, deployment, debugging distributed systems

Suggesting microservices for a startup or small team without acknowledging the overhead

Decomposing by technical layers (API service, database service) instead of business domains

Not considering data consistency challenges or suggesting two-phase commit for distributed transactions

Ignoring organizational factors—team structure, Conway’s Law, ownership models

Underestimating the infrastructure investment required—service mesh, API gateway, observability, container orchestration

---

Key Takeaways

Microservices solve organizational problems (team independence, deployment autonomy) more than technical problems. Don’t adopt them for technical reasons alone—the operational complexity is significant.

Service boundaries should follow business domains (bounded contexts), not technical layers. Each service owns a complete capability including data, business logic, and APIs. Database-per-service is non-negotiable for true independence.

The architecture introduces distributed system challenges: network failures, data consistency, cascading failures, and operational complexity. You need circuit breakers, retries, distributed tracing, and service mesh to operate reliably at scale.

Start with a modular monolith and extract services only when you have organizational reasons (multiple teams, different scaling needs). Premature decomposition is one of the most common and expensive mistakes.

Conway’s Law is real: your architecture will mirror your team structure. Align service ownership with team boundaries, and ensure each team owns their service end-to-end including on-call support.

---