Understanding Microservices Architecture
1. Understanding Microservices Principles
| Principle | Description | Implication |
|---|
| Single Responsibility | One service = one business capability | Smaller, focused codebases |
| Independent Deployment | Deploy services without coordinating others | Requires API contracts & versioning |
| Decentralized Data | Each service owns its database | No shared schemas |
| Decentralized Governance | Teams pick their own tech stack | Polyglot persistence/runtime |
| Failure Isolation | Failures contained to one service | Use bulkheads, circuit breakers |
| Automation | CI/CD, IaC, observability mandatory | High DevOps maturity required |
| Smart Endpoints, Dumb Pipes | Logic in services; transport is plain HTTP/messaging | Avoid ESB-style orchestration |
2. Comparing Monolithic vs Microservices Architecture
| Aspect | Monolith | Microservices |
|---|
| Deployment Unit | Single artifact | Many independent artifacts |
| Scaling | Whole app scales together | Scale per service |
| Database | Shared | Per-service |
| Tech Stack | Uniform | Polyglot |
| Team Structure | Centralized | Cross-functional, autonomous |
| Failure Blast Radius | Whole app | One service |
| Operational Complexity | Low | High (network, observability) |
| Best For | Small/simple apps, MVPs | Large orgs, independent domains |
3. Understanding Service Boundaries
| Boundary Driver | How to Identify | Example |
|---|
| Business Capability | Distinct organizational function | Payments, Shipping, Inventory |
| Bounded Context (DDD) | Consistent ubiquitous language | "Order" in Sales vs Fulfillment |
| Data Ownership | Single source of truth | User service owns user table |
| Rate of Change | Components changing together | Co-located deployment cadence |
| Team Ownership | One team = one service | Conway's Law alignment |
4. Understanding Microservices Benefits
| Benefit | Mechanism |
|---|
| Independent Scaling | Scale only hot services (e.g. checkout) |
| Tech Diversity | Java for billing, Go for streaming, Python for ML |
| Faster Releases | Small artifacts, parallel pipelines |
| Fault Isolation | Bulkheads prevent cascading failure |
| Team Autonomy | Reduces cross-team coordination |
| Replaceability | Rewrite/replace one service safely |
5. Understanding Microservices Challenges
| Challenge | Mitigation |
|---|
| Distributed System Complexity | Service mesh, observability stack |
| Network Latency & Failure | Retries, timeouts, circuit breakers |
| Data Consistency | Sagas, eventual consistency, CDC |
| Testing Complexity | Contract tests, ephemeral envs |
| Operational Overhead | K8s, GitOps, automated CI/CD |
| Distributed Debugging | OpenTelemetry, correlation IDs |
| Versioning Sprawl | Semantic versioning, API gateway |
6. Understanding Service Independence
| Dimension | Independent Means |
|---|
| Code | Separate repo or module; no shared mutable libs |
| Build | Independent build pipeline + artifact |
| Deploy | Released without coordination |
| Runtime | Own process/container |
| Data | Private database; no joins across services |
| Team | Owned end-to-end by one team |
7. Understanding CAP Theorem
| Property | Meaning | Trade-off |
|---|
| Consistency (C) | All nodes see same data at same time | Sacrifices availability under partition |
| Availability (A) | Every request gets a response | May return stale data |
| Partition Tolerance (P) | System works despite network splits | Mandatory in distributed systems |
| CP System | e.g. MongoDB w/ majority, etcd, Zookeeper | Reject writes during partition |
| AP System | e.g. Cassandra, DynamoDB, Couchbase | Eventually consistent |
Note: In practice you choose between CP and AP because P is non-negotiable across data centers.
8. Applying Conway's Law
| Concept | Application |
|---|
| Conway's Law | System design mirrors org communication structure |
| Inverse Conway Maneuver | Restructure teams to drive desired architecture |
| Two-Pizza Team | 6–10 people own one service end-to-end |
| Stream-Aligned Team | Owns a value stream / business capability |
| Platform Team | Provides paved-road infra for stream teams |
9. Understanding Bounded Contexts
| Element | Description |
|---|
| Bounded Context | Explicit boundary where a model applies |
| Ubiquitous Language | Terms shared by devs and domain experts within context |
| Context Map | Diagram of relationships between contexts |
| Shared Kernel | Small shared model agreed by 2 contexts |
| Anti-Corruption Layer | Translation layer protecting context purity |
Example: "Customer" in different contexts
Sales Context: Customer { id, name, leadScore, salesRep }
Billing Context: Customer { id, taxId, paymentMethods, creditLimit }
Support Context: Customer { id, tier, openTickets, satisfaction }
10. Understanding Service Granularity
| Granularity | Trade-offs |
|---|
| Too Coarse | Becomes mini-monolith; lower agility |
| Too Fine (nano) | Network overhead, distributed monolith risk |
| Right-Sized | One bounded context, owned by one team, deployed independently |
| Heuristic | "2-pizza team can own and operate it" |
11. Understanding Microservices vs SOA
| Aspect | SOA | Microservices |
|---|
| Communication | ESB (smart pipes) | Lightweight HTTP/messaging |
| Data | Often shared DB | Per-service DB |
| Governance | Centralized | Decentralized |
| Deployment | Coordinated | Independent |
| Scope | Enterprise-wide reuse | Bounded context |
12. Understanding Eventual Consistency Model
| Concept | Description |
|---|
| Eventual Consistency | Replicas converge to same state given no new writes |
| Convergence Time | Lag between write and global visibility |
| Read-Your-Writes | User sees their own write immediately |
| Monotonic Reads | Once seen, value never goes "older" |
| Causal Consistency | Causally related writes seen in order |
Warning: UI must mask convergence delay (optimistic UI, polling, websockets) or users perceive bugs.