Microservices Architecture FAQ & Answers

API Gateway pattern: 'single entry point managing client requests in microservices system, providing functionalities like routing, authentication, authorization, and data aggregation.' Purpose: simplify client, hide microservices complexity. Responsibilities: (1) Request routing: forward to appropriate service. (2) 'Cross-cutting concerns like authentication, logging, rate limiting and load balancing.' (3) Response aggregation: combine multiple service calls. (4) Protocol translation: REST to gRPC. (5) Service discovery integration: 'must use either Client-side Discovery or Server-side Discovery pattern to route requests.' Implementation: Netflix Zuul, Kong, AWS API Gateway, nginx, Envoy. Backends for Frontends (BFF): specialized API gateway per client type (mobile, web). Best practices: 'event-driven/reactive approach if must scale to handle high loads', cache responses, limit gateway logic. Essential microservices pattern.

Microservices is an architectural style that structures applications as a collection of small, independently deployable services. Each service runs in its own process and communicates via lightweight mechanisms like HTTP/REST or messaging. Key characteristics: (1) Single responsibility per service - each does one thing well. (2) Independent deployment - services can be updated without affecting others. (3) Decentralized data management - each service owns its data. (4) Technology diversity - different services can use different tech stacks. (5) Organized around business capabilities - not technical layers. This approach enables teams to work independently and scale individual components based on demand.

Monolithic architecture: single deployment unit containing all functionality, shared database, tight coupling between components, technology lock-in. Microservices: multiple independent services, separate databases per service, loose coupling via APIs, technology diversity per service. Key differences: Deployment - monolith deploys everything together, microservices deploy individually. Scaling - monolith scales as whole, microservices scale individual components. Failure impact - monolith failure affects entire app, microservices failure isolated. Team structure - monolith often single team, microservices multiple teams. Technology - monolith single stack, microservices polyglot. Choose microservices for large teams, high scale requirements, rapid evolution needs.

Service Discovery: 'enables microservices to dynamically find and communicate with each other without relying on static configurations, using service registry where services register themselves.' Problem: dynamic IP addresses, scaling, failures. Patterns: (1) Client-side discovery: client queries registry (Eureka), gets service instances, load balances. (2) Server-side discovery: load balancer/gateway queries registry. 'Service Discovery Pattern enables microservices to find and communicate using service registry where services register themselves without manual configuration.' Service registry: 'Netflix Eureka where every service registers on startup, when API Gateway needs to call another service, asks Eureka for list of alive instances.' Other tools: Consul, etcd, Zookeeper. Health checks: registry tracks service health. Best practices: 'Dynamic Service Discovery: avoid hardcoded endpoints', heartbeat mechanism, cache registry data. Essential microservices infrastructure.

Event-Driven Architecture (EDA): 'services react to events rather than direct calls, using message queues or pub/sub systems to decouple services.' 'Helps achieve loose coupling between services so many components work in parallel, minimizing chances of bottleneck formation.' How it works: (1) Service publishes event/message to broker (RabbitMQ, Kafka, AWS SNS/SQS). (2) One or more services subscribe to event. (3) When message published, broker delivers to subscribers. Benefits: (1) Loose coupling: services don't know consumers. (2) Scalability: process events independently. (3) Resilience: continues if consumer down. (4) Extensibility: add consumers without changing publisher. Patterns: pub/sub (one-to-many), queue (one-to-one), stream processing (Kafka). Use cases: notifications, data synchronization, workflow orchestration. Best practices (2025): 'Asynchronous Communication increases resilience and decouples service failures.' Essential microservices pattern.

Saga pattern manages distributed transactions across microservices as a sequence of local transactions with compensating actions for rollback. Two approaches: (1) Choreography: services emit events, others react (decentralized, scalable). Example: OrderCreated → InventoryService reserves stock, publishes InventoryReserved → PaymentService charges card. Simple flows, loose coupling. (2) Orchestration: central coordinator (Temporal, Camunda, AWS Step Functions) manages workflow. Better visibility, easier debugging, centralized monitoring. Complex workflows. Implementation essentials: idempotent operations (handle duplicates), compensating transactions (undo completed steps), Saga Log (track progress). 2025 trend: hybrid approach - simple flows use choreography, complex flows use orchestration. Best practice: always implement timeout handling and retry logic. Essential for maintaining consistency without distributed locks in microservices.

CQRS (Command Query Responsibility Segregation) separates read and write models for independent optimization. Write model: handles commands (create, update, delete), normalized schema, business logic validation, publishes events. Read model: handles queries, denormalized views optimized for specific queries, eventually consistent. Implementation: (1) Simple - shared database, separate models. (2) Advanced - separate databases (PostgreSQL for writes, Elasticsearch for reads), event-driven synchronization. Often combined with Event Sourcing: store all changes as chronological events, replay events to rebuild state, complete audit trail. Use when: read/write load imbalance (10:1 ratio+), complex queries spanning multiple aggregates, audit requirements, performance-critical reads. Avoid when: simple CRUD apps, small scale. Frameworks: Axon Framework (Java), Eventuate, AWS services (Kinesis + EventBridge). Essential for high-scale microservices with complex query requirements.

Circuit Breaker prevents cascading failures by stopping calls to failing services once errors exceed thresholds. States: (1) Closed - normal operation, calls pass through, failures counted in sliding window. (2) Open - threshold reached, all calls fail immediately without calling service. (3) Half-Open - after wait duration, test limited calls; if succeed → Closed, if fail → Open. Additional states (Resilience4j 2025): DISABLED (always allow), FORCED_OPEN (always deny), METRICS_ONLY (collect stats only). Implementation: Resilience4j (Java/Spring Boot standard 2025), Polly (.NET), failsafe-go (Go). Configuration example: failureRateThreshold: 50% (open if 50% fail), slidingWindowSize: 100 (last 100 calls), waitDurationInOpenState: 60s (stay open 60s), permittedNumberOfCallsInHalfOpenState: 10 (test with 10 calls). Monitoring: Spring Boot Actuator endpoints /actuator/health, /actuator/metrics for circuit breaker states. Fallback pattern: provide default/cached response when circuit open. Best practices (2025): combine with Retry and Bulkhead patterns, set realistic thresholds based on service SLAs, regularly review circuit states. Resilience4j integrates seamlessly with Spring Boot via annotations @CircuitBreaker. Essential for fault-tolerant microservices preventing system-wide failures.

Database per Service: each microservice has its own database, not shared. Benefits: (1) Loose coupling: services independent, change database schema without affecting others. (2) Technology choice: use appropriate database for service (PostgreSQL, MongoDB, Redis). (3) Scalability: scale database per service needs. (4) Failure isolation: database issues don't affect all services. Challenges: (1) Data consistency: no ACID transactions across services (use Saga). (2) Queries: can't join across databases (use API composition or CQRS). (3) Data duplication: intentional redundancy (denormalization). (4) Eventual consistency: must accept. Implementation: separate databases (preferred), schemas, or tables (least separation). Best practice: strict database ownership, API for data access (no direct DB queries), event-driven data synchronization. Shared database anti-pattern: multiple services sharing database (tight coupling). Essential microservices principle.

Service Mesh provides infrastructure layer for service-to-service communication with observability, security, and resilience. Architecture: (1) Data plane: sidecar proxies (Envoy) intercept all traffic. (2) Control plane: manages proxies and policies. Top solutions (2025): Linkerd (fastest, minimal overhead, simplest, CNCF graduated), Istio (feature-rich, enterprise-grade, Ambient mode for sidecarless deployment), Cilium (eBPF-based, CNI + service mesh). Key features: automatic mTLS encryption (zero-trust), distributed tracing, traffic routing, circuit breakers, retries. Performance: Linkerd adds ~8% latency, Istio ~25-35%, Cilium ~30-40% vs baseline. Use when: 10+ services, zero-trust security required, complex traffic management. 2025 trends: sidecarless architectures (Istio Ambient, Cilium), eBPF adoption, CNCF standardization. Essential for secure, observable microservices at scale.

Eventual consistency accepts temporary data inconsistencies across services, resolving them over time through asynchronous updates. Pattern: (1) Service updates its local database immediately. (2) Service publishes event about the change. (3) Other services consume events and update their local data. (4) System eventually reaches consistent state. Trade-offs: strong consistency requires distributed transactions (slow, complex), eventual consistency provides availability and partition tolerance (CAP theorem). Implementation: message brokers (Kafka, RabbitMQ) guarantee event delivery, idempotent handlers handle duplicate events, compensating actions fix errors. Example: Order service marks order as PAID, publishes OrderPaid event, Inventory service consumes and reduces stock levels. Temporarily, order shows paid but inventory not yet updated - eventually consistent. Monitor consistency lag with metrics.

API composition implements cross-service queries by orchestrating multiple API calls and combining results. Pattern: (1) Composer receives query. (2) Decomposes into sub-queries per service. (3) Calls services in parallel for performance. (4) Aggregates results. (5) Returns unified response. Implementations: (1) API Gateway composition - simple aggregation logic. (2) BFF (Backend for Frontend) - specialized per client type. (3) GraphQL with Apollo Federation - single query across multiple services, schema stitching. (4) Custom Composer service - complex transformations. Example: Product page query → parallel calls to ProductService (details), InventoryService (stock), ReviewService (ratings) → combine into single response. Challenges: response time = slowest service, error handling (partial failures), caching strategy. 2025 best practice: use GraphQL Federation for flexible client queries, implement response caching, timeout handling. Essential for read-heavy microservices.

Centralized logging aggregates logs from all microservices into a single searchable system. Each service writes structured logs (JSON format) with correlation IDs to trace requests across services. Implementation pattern: service → log shipper (Fluentd/Logstash) → centralized storage (Elasticsearch/Loki) → visualization (Kibana/Grafana). Key practices: (1) Structured logging with consistent fields (timestamp, service, traceId, level, message). (2) Correlation IDs passed via HTTP headers or message metadata. (3) Log levels: ERROR, WARN, INFO, DEBUG. (4) Async logging to prevent performance impact. Popular stacks: ELK (Elasticsearch, Logstash, Kibana), EFK (Elasticsearch, Fluentd, Kibana), Grafana Loki, AWS CloudWatch Logs, Azure Monitor. Essential for debugging distributed systems and understanding request flows.

Metrics collection provides quantitative insights into microservices performance and health. Key metrics: (1) RED method - Rate (requests/sec), Errors (failure rate), Duration (response time). (2) Google's FOUR golden signals - Latency, Traffic, Errors, Saturation. Implementation: expose metrics endpoint (/metrics) in Prometheus format from each service. Libraries: Prometheus client libraries, Micrometer (Java), OpenTelemetry. Collection architecture: services expose metrics → Prometheus scrapes → Grafana visualizes. Best practices: (1) Custom business metrics beyond system metrics. (2) Histograms for request latency distribution. (3) Gauges for current state (connections, queue size). (4) Counters for cumulative values. Alert on SLO violations: 95th percentile latency < 500ms, error rate < 1%, uptime > 99.9%.

Distributed tracing tracks requests as they flow through multiple microservices, providing end-to-end visibility. Components: (1) Trace ID - unique identifier for entire request journey. (2) Span ID - identifier for operation in single service. (3) Span - operation with timing, metadata, parent-child relationships. Implementation: OpenTelemetry SDK instruments services automatically or manually. Trace context propagation via HTTP headers (traceparent, tracestate). Architecture: services → OpenTelemetry Collector → Jaeger/Zipkin/tempo → visualization. Key data: service names, operation names, duration, tags, logs. Use cases: (1) Performance bottleneck identification. (2) Error root cause analysis. (3) Service dependency mapping. Sample trace: API Gateway → User Service (50ms) → Order Service (200ms) → Payment Service (150ms) → total 450ms.

Authentication in microservices uses OAuth2/OIDC with JWT tokens for stateless authentication. Architecture: (1) Client authenticates with Authorization Server (Keycloak, Auth0, Okta). (2) Receives JWT token containing user identity and claims. (3) API Gateway validates JWT signature and expiration. (4) Gateway passes user context to downstream services via headers. JWT structure: header (algorithm), payload (sub, exp, roles, scopes), signature. Benefits: stateless (no session storage), scalable, self-contained verification. Implementation: API Gateway middleware validates token, extracts claims, adds X-User-ID and X-Roles headers. Services trust headers from gateway (internal network security). Refresh tokens for long-lived sessions. Sample JWT flow: Login → JWT → API Gateway validation → Service receives user context.

Mutual TLS (mTLS) provides bidirectional authentication where both client and server verify each other's identity using X.509 certificates, fundamental to zero-trust security. How it works: (1) Each service has certificate signed by internal Certificate Authority. (2) During TLS handshake, both parties present certificates. (3) Certificates validated before connection established. Implementation: Service mesh (Istio, Linkerd, Cilium) automates mTLS via sidecar proxies - handles certificate generation, rotation, verification without code changes. Benefits: workload identity, encrypted communication, no shared secrets. 2025 adoption: 79% of CNCF respondents use service mesh primarily for mTLS security, 70% in production. Configuration: Istio PeerAuthentication enforces STRICT mode, AuthorizationPolicy restricts access. Performance impact: Linkerd adds ~8% latency, Istio ~25-35%. Essential for zero-trust microservices where "never trust, always verify" principle applies.

Secrets management stores and distributes sensitive data (API keys, database passwords, certificates) securely to microservices. Requirements: (1) Encryption at rest and in transit. (2) Access control and audit logging. (3) Automatic rotation. (4) Integration with deployment platforms. Solutions: (1) HashiCorp Vault - central secrets hub with dynamic secrets. (2) Cloud provider solutions - AWS Secrets Manager, Azure Key Vault, Google Secret Manager. (3) Kubernetes Secrets - native but base64 encoded (not encrypted by default). Best practices: (1) Never store secrets in code or config files. (2) Use short-lived dynamic secrets. (3) Inject secrets via environment variables or mounted files. (4) Audit access patterns. (5) Principle of least privilege - only needed secrets per service. Sample Vault integration: service authenticates via Kubernetes auth, retrieves database credential with 1-hour TTL.

Contract testing verifies API contracts between services without full integration tests. Consumer-driven approach: (1) Consumer writes tests defining expected requests/responses from provider. (2) Consumer publishes contract to Pact Broker. (3) Provider runs tests against all consumer contracts. (4) Both sides verify contracts in CI pipeline. Tools: Pact (most popular, language-agnostic JSON contracts, supports multiple languages), Spring Cloud Contract (Java/Spring, producer-driven option, hand-written DSL contracts). Key difference: Pact generates contracts from consumer code automatically, Spring Cloud Contract requires manual contract writing. Benefits: fast feedback without network calls, independent testing, breaking change detection before deployment, contracts as living documentation. 2025 trend: 85% of enterprises increasing microservices adoption, making contract testing essential. CI integration: consumer publishes on build, provider verifies continuously. Essential for safe deployments across teams.

Chaos testing proactively introduces failures to test system resilience and fault tolerance. Principles: (1) Regularly test failure scenarios. (2) Start small, increase blast radius. (3) Run in production-like environments. (4) Automate experiments. Common experiments: (1) Pod deletion - Kubernetes kills random pods. (2) Network latency - add delay between services. (3) Network partition - isolate services from each other. (4) Resource exhaustion - consume CPU/memory. (5) Database failures - disconnect from database. Tools: Chaos Monkey (Netflix), Litmus Chaos, Gremlin, Chaos Mesh. Implementation: GameDay exercises where teams deliberately break systems to learn resilience. Sample Chaos Monkey config: kill 1 instance every weekday at 10am. Expected behavior: (1) Circuit breakers activate. (2) Fallback responses returned. (3) Autoscaling replaces instances. (4) Users experience minimal disruption.

Strangler Fig pattern incrementally migrates monolith to microservices by gradually replacing functionality while maintaining business continuity. Named after strangler fig vines that grow around host trees. Process: (1) Analyze monolith, identify bounded contexts and dependencies. (2) Build new microservice for extracted functionality. (3) API Gateway/proxy routes traffic - new requests to microservice, others to monolith. (4) Implement anti-corruption layer (adapter converting calls between systems). (5) Manage data synchronization (dual writes, CDC, migration services). (6) Repeat until monolith fully replaced. Benefits: low risk incremental approach, delivers business value during migration, immediate modernization per service. Challenges: proxy can become bottleneck, data synchronization complexity. 2025 best practices: comprehensive analysis first, start with independent features, monitor both systems, plan for long coexistence period. Essential migration strategy recommended by AWS, Azure, and Martin Fowler.

Service orchestration uses central coordinator to manage workflow by explicitly calling services in defined sequence. Orchestrator controls flow: (1) Receives initial request. (2) Calls services sequentially or parallel. (3) Handles business logic, error handling, compensation. (4) Coordinates rollback if failures occur. Implementation: Temporal (durable workflows with timeouts/retries), Camunda (BPMN workflows, visual modeling), AWS Step Functions (serverless state machines), Zeebe (cloud-native orchestration). Example: OrderOrchestrator → InventoryService.reserve() → PaymentService.charge() → ShippingService.schedule() → complete. Benefits: centralized logic (easier debugging), clear workflow visibility, explicit error handling, state management. Drawbacks: orchestrator is single point of failure, service coupling. Use when: complex workflows, many services coordination, need transaction-like guarantees, monitoring critical. 2025 trend: Temporal adoption for complex workflows with built-in reliability.

Service choreography coordinates services through events without central controller, enabling decentralized workflows. Pattern: (1) Service performs action, publishes domain event. (2) Other services subscribe to relevant events, react independently. (3) Each service owns its business logic portion. (4) Emergent workflow from event interactions. Implementation: Kafka (event streaming, message replay), RabbitMQ (message broker, routing flexibility), AWS SNS/SQS (pub/sub), Azure Service Bus. Example: OrderService publishes OrderCreated → InventoryService reserves stock, publishes InventoryReserved → PaymentService charges card, publishes PaymentCompleted → ShippingService schedules delivery. Benefits: no single point of failure, highly scalable, loose coupling, services evolve independently. Challenges: difficult to visualize complete flow, complex debugging, event ordering issues. Use when: simple event-driven flows, loose coupling priority, high scalability needed. 2025 best practice: use for simple sagas, combine with orchestration for complex workflows.

API-first design treats APIs as first-class products, designing them before implementation. Process: (1) Define API contract using OpenAPI/Swagger specification. (2) Review and validate contract with stakeholders. (3) Generate server stubs and client SDKs from specification. (4) Implement business logic adhering to contract. Benefits: (1) Parallel development - frontend and backend can work simultaneously. (2) Contract testing prevents breaking changes. (3) Clear documentation serves as living spec. (4) Consistency across services. Tools: Swagger/OpenAPI editor, Postman for API testing, API Gateway for contract enforcement. Example OpenAPI structure: paths (/users), operations (GET/POST), schemas (User), responses (200/400/500). Best practices: version APIs from start (v1), use semantic versioning, include examples, document error responses. Essential for large microservices ecosystems with multiple consumer teams.

Health checks provide standardized endpoints to monitor microservice health and readiness. Types: (1) Liveness probe - checks if service is alive (restart if fails). (2) Readiness probe - checks if service can accept traffic (remove from load balancer if fails). (3) Startup probe - checks if service started successfully. Implementation: HTTP endpoints returning appropriate status codes and detailed health information. Example: GET /health returns {'status': 'healthy', 'checks': {'database': 'ok', 'cache': 'ok', 'external_api': 'degraded'}}. Health check best practices: (1) Fast responses (<1 second). (2) Check critical dependencies (database, cache). (3) Don't include expensive operations. (4) Return HTTP 200 for healthy, 503 for unhealthy. Kubernetes integration: configure liveness/readiness probes in Deployment spec. Monitoring: use health check data for alerting and automated recovery.

Distributed monolith occurs when microservices are so tightly coupled that they must be deployed together, defeating microservices benefits. Symptoms: (1) Services must deploy simultaneously due to dependencies. (2) Changes ripple across multiple services. (3) Services share databases or have synchronous dependency chains. (4) Cannot scale services independently. Causes: (1) Poor service boundaries based on technical layers. (2) Shared databases across services. (3) Excessive synchronous communication. (4) Violation of single responsibility principle. Example: UserService calls OrderService which calls PaymentService - all must change and deploy together. Fix: (1) Redefine service boundaries around business capabilities. (2) Implement database per service. (3) Use asynchronous communication. (4) Apply Strangler Fig pattern to extract independent services. Test for distributed monolith: can you deploy services independently? Can individual services scale?

Shared database anti-pattern occurs when multiple microservices access same database, creating tight coupling that defeats microservices benefits. Problems: (1) Schema changes require coordination across all services - break one, break all. (2) Services bypass APIs, directly access data (violating encapsulation). (3) Database becomes single point of failure and bottleneck. (4) Cannot choose optimal database per service (PostgreSQL vs MongoDB vs Redis). (5) Impossible to scale or deploy services independently. (6) Transaction boundaries unclear. Example: OrderService and InventoryService sharing ORDERS table - schema change breaks InventoryService. Solutions: (1) Database per service pattern - strict ownership. (2) API-based data access only. (3) Event-driven synchronization for shared data needs. (4) CQRS for separate read/write models. Temporary: separate schemas in same DB instance, plan migration to full separation. Shared database indicates poorly defined service boundaries - refine based on bounded contexts.

Nano-services anti-pattern occurs when services are excessively granular, creating more problems than benefits. Symptoms: (1) Services with single trivial operations (GetUserName as separate service). (2) Excessive network calls for simple flows (5+ calls for one business operation). (3) Services with <100 lines of code or single function. (4) High operational overhead for minimal business value. Problems: network latency multiplied (100ms × 5 calls = 500ms), deployment complexity (manage 50+ services), difficult to trace business flows, distributed debugging overhead, increased failure points. Example anti-pattern: UserService, UserNameService, UserEmailService, UserAddressService instead of cohesive UserService. Right-sizing principles: (1) Bounded context alignment - service owns complete business capability. (2) Team ownership - single team can maintain. (3) Independent evolution - deployable without coordinating others. (4) Business value - provides meaningful functionality. Balance: avoid both nano-services and monoliths.

Use microservices when: (1) Multiple autonomous teams (10+ developers). (2) Different scaling requirements per component. (3) Rapid independent deployments needed. (4) Technology diversity beneficial. (5) High availability critical (isolate failures). (6) Existing monolith too complex. Use monolith when: (1) Small team (<10 people). (2) Simple domain. (3) Startup/MVP (speed over scale). (4) Uncertain requirements (monolith easier to refactor). (5) Limited DevOps maturity. (6) Cost constraints (microservices require more infrastructure). Martin Fowler's guidance: "almost always start with monolith" - build well-structured modular monolith, extract microservices when clear boundaries emerge, team structure matters (Conway's Law). Migration path: Strangler Fig pattern for incremental extraction. 2025 reality: 85% of enterprises increasing microservices adoption, but premature microservices remains common mistake. Prerequisites: CI/CD, monitoring, service mesh, container orchestration.

Cache-aside (lazy loading) pattern gives applications explicit cache control. Read flow: (1) Check cache first. (2) Cache hit - return cached data. (3) Cache miss - query database, populate cache with TTL, return data. Write flow: (1) Update database. (2) Invalidate cache entry (safest) or update cache (risky - race conditions). Redis implementation: result = redis.get('user:123'); if (!result) { result = db.query('SELECT * FROM users WHERE id=123'); redis.setex('user:123', 3600, result); }. Key design: namespace:entity:id format ('user:123', 'product:456'). TTL strategy: frequently changing data (60s), semi-static (1 hour), static (24 hours). Monitoring: track cache hit ratio (target 80-90%), miss rate, latency. Benefits: simple, works with any cache (Redis, Memcached), graceful degradation on cache failure. Use for: read-heavy workloads, tolerant of eventual consistency. Alternative: write-through (update cache on writes).

Cache invalidation maintains data consistency when underlying data changes - one of "two hard things in computer science" (Phil Karlton). Strategies: (1) TTL expiration: automatic expiry after duration (simple but serves stale data until expiry). (2) Event-driven invalidation: service publishes DataUpdated event → subscribers invalidate affected cache keys (most reliable). (3) Write-through: update cache and database atomically. (4) Write-behind: update cache immediately, database async. Event-driven pattern: db.update(user); eventBus.publish('user.updated', userId); cache.delete('user:' + userId);. Challenges: race conditions (update/invalidate ordering), cascading invalidations (related data), network partitions (stale cache in isolated nodes). Best practices: short TTLs for frequently changing data (5-60 seconds), versioned cache keys (user:123:v2 when schema changes), lazy invalidation (accept brief staleness), monitor staleness lag metrics. 2025 approach: combine TTL + event-driven for balance.

Containerization packages microservices with all dependencies into lightweight, isolated containers. Docker is the industry standard (2025) for containerizing microservices. Benefits: (1) Consistency - same environment dev/test/prod. (2) Isolation - services don't interfere with each other. (3) Portability - run anywhere Docker is installed. (4) Efficiency - share host OS kernel, faster startup than VMs. Dockerfile example: FROM node:18-alpine → WORKDIR /app → COPY package*.json ./ → RUN npm ci → COPY . . → EXPOSE 3000 → CMD ['npm', 'start']. Best practices: (1) One process per container. (2) Use minimal base images (alpine). (3) Multi-stage builds for smaller final images. (4) Don't run as root user. (5) Include health checks. Docker Compose for local development: define multi-service environment with networking and volumes. Essential for microservices deployment consistency.

Kubernetes (K8s) orchestrates containerized microservices at scale, providing automated deployment, scaling, and management. Core concepts: (1) Pods - smallest deployable units (1+ containers). (2) Deployments - declarative pod management with rolling updates. (3) Services - stable network endpoints via internal DNS. (4) ConfigMaps/Secrets - configuration and sensitive data. (5) Ingress - external traffic routing. Key features: (1) Self-healing - restarts failed pods, replaces nodes. (2) Horizontal scaling - auto-scale based on CPU/memory/custom metrics. (3) Load balancing - distributes traffic across healthy pods. (4) Rolling updates - zero-downtime deployments. Sample deployment: 3 replicas, resource limits, health checks, readiness probes. Production best practices: resource requests/limits, liveness/readiness probes, pod disruption budgets, network policies.

GitOps uses Git as the single source of truth for infrastructure and application deployment. Process: (1) Declare desired state in Git (Kubernetes manifests, Helm charts). (2) Automated tool (ArgoCD, Flux) compares Git state to cluster state. (3) Tool applies changes to make cluster match Git. (4) Git commits record all changes for audit trail. Benefits: (1) Declarative configuration - version controlled infrastructure. (2) Automated drift detection - manual changes revert automatically. (3) Git-based workflows - pull requests for changes, code reviews for infrastructure. (4) Rollback via Git revert. Example ArgoCD workflow: push to Git → ArgoCD detects changes → applies to Kubernetes → reports status. Best practices: (1) Separate Git repos per environment or branch strategy. (2) Immutable tags for deployments. (3) Secrets management outside Git (Vault, SealedSecrets). (4) Policy enforcement (OPA Gatekeeper). GitOps enables reliable, auditable microservices deployments at scale.

Feature flags decouple code deployment from feature release, enabling controlled rollouts and instant rollbacks. Architecture: (1) Feature flag service (LaunchDarkly, Unleash, OpenFeature) stores configurations. (2) Services evaluate flags at runtime. (3) Admin dashboard controls flags without deployment. Patterns: (1) Boolean toggles - simple on/off. (2) Percentage rollout - gradual (1% → 10% → 50% → 100%). (3) Targeted rollout - specific users/segments. (4) A/B testing - compare variations. Code: if (flags.isEnabled('new-payment-flow')) { newFlow() } else { oldFlow() }. 2025 trend: OpenFeature standardization (CNCF project) - vendor-neutral API, swap providers without code changes. Benefits: instant kill switch, canary releases, production testing with limited blast radius, rapid rollback without redeployment. Best practices: clean up old flags (technical debt), monitor flag performance impact, consistent naming conventions, default to safe behavior. Essential for safe microservices deployments.

SOA (Service-Oriented Architecture) and microservices share service-based philosophy but differ significantly in implementation. Key differences: (1) Scope: SOA enterprise-wide integration via ESB, microservices application-specific. (2) Service size: SOA services larger (coarse-grained), microservices smaller (fine-grained, single responsibility). (3) Data management: SOA commonly shares databases, microservices enforce database per service. (4) Communication: SOA uses SOAP/ESB (heavyweight protocol), microservices use REST/gRPC/messaging (lightweight). (5) Deployment: SOA often monolithic deployment, microservices independently deployable. (6) Governance: SOA centralized via ESB, microservices decentralized. (7) Philosophy: SOA uses "smart pipes" (ESB contains logic), microservices use "smart endpoints, dumb pipes" (logic in services). Evolution context: microservices evolved from SOA lessons, refined for cloud-native architectures. Understanding shows architectural progression from 2000s SOA to modern microservices.

API versioning maintains backward compatibility while evolving APIs. Strategies: (1) URI versioning: /v1/users, /v2/users - simple, explicit, most common. (2) Header versioning: Accept: application/vnd.api+json;version=2 - clean URLs, less visible. (3) Query parameter: /users?version=2 - flexible but less common. Critical principle: consistency across all microservices - single uniform approach essential. Best practices: avoid breaking changes (additive changes, optional fields, deprecation periods), use semantic versioning (major.minor.patch), version from day one (start with v1). API Gateway routes versions to appropriate service versions. GraphQL advantage: built-in evolution without versioning - add fields without breaking changes, deprecation support. 2025 trend: REST remains dominant but GraphQL adoption growing for flexible client queries. Deprecation process: announce clearly, support migration period (6-12 months), sunset old versions. Essential for managing API evolution at scale.

Choose REST for: (1) Public-facing APIs (web browsers, mobile apps). (2) Simple CRUD operations. (3) External integrations. (4) When JSON format preferred. Benefits: human-readable, browser-compatible, widely supported, simple debugging. Choose gRPC for: (1) Internal service-to-service communication. (2) High-performance requirements. (3) Strict contract enforcement. (4) Streaming operations. Benefits: binary Protocol Buffers (3-5x smaller than JSON), HTTP/2 multiplexing, code generation for multiple languages, built-in streaming. Performance comparison: gRPC ~10-50ms vs REST ~50-200ms for same operation. Implementation: REST uses HTTP verbs (GET/POST/PUT/DELETE), gRPC uses .proto service definitions with methods. Best practice: REST for external APIs, gRPC for internal microservices communication where performance matters.

Message queues (RabbitMQ, AWS SQS, Azure Service Bus) provide point-to-point messaging with delivery guarantees. Pattern: producer → queue → single consumer. Message deleted after consumption. Use for: task distribution, command processing (imperative - "charge payment"), load balancing, work queues. Guarantees: at-least-once delivery, message acknowledgment, persistence. Event streaming (Kafka, AWS Kinesis, Pulsar) provides publish-subscribe with persistent, replayable log. Pattern: producer → topic → multiple consumers. Messages retained (hours to forever). Use for: event sourcing (declarative - "payment charged"), data pipelines, real-time analytics, audit logs, CQRS read model updates. Features: consumer replay from any offset, log compaction, partitioning, high throughput (millions msgs/sec). Key difference: queues = ephemeral commands (deleted), streaming = durable events (retained). Choose queues for commands, streaming for events. Example: use queue for "process order" task, streaming for "order created" event.

Blue-green deployment maintains two identical production environments (blue=current, green=new) for zero-downtime deployments. Process: (1) Deploy new version to green environment. (2) Run smoke tests against green. (3) Switch traffic from blue to green via load balancer. (4) Keep blue running for immediate rollback if needed. (5) Decommission blue after confirmation. Traffic switching methods: (1) DNS change (slow). (2) Load balancer reconfiguration (instant). (3) Service mesh routing (instant). Kubernetes implementation: two Deployments, one Service pointing to active deployment via selector label change. Benefits: instant rollback (switch back to blue), zero downtime, full testing in production environment. Requirements: double infrastructure cost, database schema changes must be backward compatible, stateful applications need data migration planning.

Canary deployment gradually rolls out new version to subset of users, monitoring for issues before full rollout. Process: (1) Deploy new version alongside current version. (2) Route small percentage (1-5%) of traffic to new version. (3) Monitor metrics (error rate, latency, business KPIs). (4) Gradually increase traffic if healthy (10% → 25% → 50% → 100%). (5) Rollback immediately if issues detected. Traffic routing: (1) Load balancer weighting. (2) Service mesh (Istio VirtualService, Linkerd). (3) Feature flags. Monitoring key metrics: error rate < threshold, 95th percentile latency < baseline, conversion rates stable. Automated rollback: if error rate increases by >50% or latency spikes >2x, automatically reduce traffic to 0%. Popular in microservices due to quick recovery from failures and real user feedback.

Circuit Breaker prevents cascading failures by stopping calls to failing services once errors exceed thresholds. States: (1) Closed - normal operation, failures counted in sliding window. (2) Open - threshold reached, all calls fail immediately. (3) Half-Open - after wait period, test limited calls; success → Closed, failure → Open. Configuration example (Resilience4j): failureRateThreshold: 50% (open if 50% fail), slidingWindowSize: 100 (last 100 calls), waitDurationInOpenState: 60s (stay open 60s), permittedNumberOfCallsInHalfOpenState: 10 (test with 10). Monitoring: Spring Boot Actuator exposes /actuator/health and /actuator/metrics. Combine with Retry and Bulkhead patterns. Resilience4j integrates with Spring Boot via @CircuitBreaker annotation. Essential for fault-tolerant microservices.

Service Mesh provides infrastructure layer for service-to-service communication with observability, security, and resilience. Architecture: data plane (sidecar proxies intercept traffic) + control plane (manages proxies). Top solutions (2025): Linkerd (fastest, minimal overhead ~8% latency, simplest, CNCF graduated), Istio (feature-rich, Ambient mode for sidecarless deployment, ~25-35% latency overhead), Cilium (eBPF-based, CNI + service mesh, ~30-40% overhead). Key features: automatic mTLS encryption (zero-trust), distributed tracing, traffic routing, circuit breakers, retries. Use when: 10+ services, zero-trust security required, complex traffic management. 2025 trends: sidecarless architectures (Istio Ambient, Cilium), eBPF adoption. Essential for secure, observable microservices at scale.

Mutual TLS (mTLS) provides bidirectional authentication where both client and server verify identities using X.509 certificates. How it works: (1) Each service has certificate signed by internal CA. (2) During TLS handshake, both parties present certificates. (3) Certificates validated before connection established. Service mesh (Istio, Linkerd, Cilium) automates mTLS via sidecar proxies - handles certificate generation, rotation, verification without code changes. Benefits: workload identity, encrypted communication, no shared secrets. 2025 adoption: 79% of CNCF respondents use service mesh primarily for mTLS security. Configuration: Istio PeerAuthentication enforces STRICT mode, AuthorizationPolicy restricts access. Performance: Linkerd adds ~8% latency, Istio ~25-35%. Essential for zero-trust microservices where "never trust, always verify" principle applies.

CQRS (Command Query Responsibility Segregation) separates read and write models for independent optimization. Write model: handles commands (create/update/delete), normalized schema, business logic. Read model: handles queries, denormalized views optimized for queries, eventually consistent. Implementation: (1) Simple - shared database, separate models. (2) Advanced - separate databases (PostgreSQL for writes, Elasticsearch for reads), event-driven sync. Often combined with Event Sourcing: store all changes as events, replay to rebuild state, complete audit trail. Use when: read/write load imbalance (10:1 ratio+), complex queries spanning aggregates, audit requirements, performance-critical reads. Avoid for: simple CRUD apps, small scale. Frameworks: Axon Framework (Java), Eventuate, AWS Kinesis + EventBridge.

Strangler Fig incrementally migrates monolith to microservices while maintaining business continuity. Process: (1) Analyze monolith, identify bounded contexts. (2) Build new microservice for extracted functionality. (3) API Gateway routes traffic - new requests to microservice, others to monolith. (4) Implement anti-corruption layer (adapter between systems). (5) Manage data synchronization (dual writes, CDC). (6) Repeat until monolith replaced. Benefits: low risk incremental approach, delivers value during migration, immediate modernization per service. Challenges: proxy can bottleneck, data sync complexity. 2025 best practices: comprehensive analysis first, start with independent features, monitor both systems, plan long coexistence. Essential migration strategy recommended by AWS, Azure, Martin Fowler.

Contract testing verifies API contracts between services without full integration tests. Consumer-driven approach: (1) Consumer writes tests defining expected requests/responses. (2) Consumer publishes contract to Pact Broker. (3) Provider runs tests against all consumer contracts. (4) Both sides verify in CI pipeline. Tools: Pact (most popular, auto-generates contracts from consumer code, language-agnostic JSON), Spring Cloud Contract (Java/Spring, hand-written DSL). Benefits: fast feedback without network calls, independent testing, breaking change detection before deployment, contracts as living documentation. 2025 trend: 85% of enterprises increasing microservices adoption, making contract testing essential. CI integration: consumer publishes on build, provider verifies continuously. Essential for safe deployments across teams.