Deployment Topology
Design deployment architectures with high availability, automatic scaling, health management, and service discovery.
Context
You are planning how services are deployed and scaled. Design topology for HA, choose orchestration platform, plan service communication, and manage state. Read current deployment practices, SLA requirements, and team operational maturity.
Domain Context
Based on container orchestration and deployment patterns:
- Container Orchestration: Kubernetes (manual control, cloud-agnostic), ECS (AWS-native), Cloud Run (serverless)
- Service Discovery: Automatic registration/deregistration; clients find healthy instances
- Load Balancing: Distribute traffic across instances; internal (mesh) and external (ingress)
- Health Checks: Liveness (restart if dead), readiness (traffic if ready), startup probes
- Rolling Updates: Gradual replacement of old instances with new; zero-downtime deployments
Instructions
Choose Orchestration Platform: Kubernetes for multi-cloud, complex services. ECS for AWS-only, simpler setup. Cloud Run/App Engine for stateless workloads.
Design Service Topology: How many replicas per service? Plan for peak load + buffer. Multi-AZ for resilience. Blue-green deployments for safe rollouts.
Implement Service Discovery: Kubernetes: DNS service records. ECS: load balancer targets. Clients discover healthy endpoints automatically.
Plan Load Balancing: External load balancer for ingress. Service mesh (Istio) for internal traffic management, circuit breaking, retries.
Configure Health Checks: Readiness probe: app ready to serve? Liveness probe: process alive? Startup probe: give time to initialize. Tune thresholds to avoid flaky restarts.
Anti-Patterns
- Too Many Replicas: Set replicas to 10 for small service. Result: cost, complexity, no benefit. Guard: Calculate required capacity; auto-scale based on CPU/memory, not arbitrary numbers.
- Health Checks Too Strict: Fail readiness on any non-200 response. Result: cascading failures, thrashing restarts. Guard: Design probes to be lenient on transient errors; only fail on persistent issues.
- No Graceful Shutdown: Kill processes immediately. Result: in-flight requests dropped. Guard: Drain connections; wait for graceful shutdown before kill.
- Ignoring Service Mesh Complexity: Add service mesh (Istio) for features you don't need. Result: operational overhead, debugging difficulty. Guard: Start simple; add mesh when you need advanced features (traffic splitting, security policies).
Further Reading
- Kubernetes in Action by Marko Luksa — Kubernetes deployment patterns
- Site Reliability Engineering by Google — production deployment practices
- The Phoenix Project by Gene Kim — deployment culture and practices
1---2name: deployment-topology3description: Plan container orchestration, load balancing, high availability, and scaling. Design deployment topologies for production systems. Use when architecting deployment infrastructure or modernizing deployment practices.4---56# Deployment Topology78Design deployment architectures with high availability, automatic scaling, health management, and service discovery.910## Context1112You are planning how services are deployed and scaled. Design topology for HA, choose orchestration platform, plan service communication, and manage state. Read current deployment practices, SLA requirements, and team operational maturity.1314## Domain Context1516Based on container orchestration and deployment patterns:1718- **Container Orchestration**: Kubernetes (manual control, cloud-agnostic), ECS (AWS-native), Cloud Run (serverless)19- **Service Discovery**: Automatic registration/deregistration; clients find healthy instances20- **Load Balancing**: Distribute traffic across instances; internal (mesh) and external (ingress)21- **Health Checks**: Liveness (restart if dead), readiness (traffic if ready), startup probes22- **Rolling Updates**: Gradual replacement of old instances with new; zero-downtime deployments2324## Instructions25261. **Choose Orchestration Platform**: Kubernetes for multi-cloud, complex services. ECS for AWS-only, simpler setup. Cloud Run/App Engine for stateless workloads.27282. **Design Service Topology**: How many replicas per service? Plan for peak load + buffer. Multi-AZ for resilience. Blue-green deployments for safe rollouts.29303. **Implement Service Discovery**: Kubernetes: DNS service records. ECS: load balancer targets. Clients discover healthy endpoints automatically.31324. **Plan Load Balancing**: External load balancer for ingress. Service mesh (Istio) for internal traffic management, circuit breaking, retries.33345. **Configure Health Checks**: Readiness probe: app ready to serve? Liveness probe: process alive? Startup probe: give time to initialize. Tune thresholds to avoid flaky restarts.3536## Anti-Patterns3738- **Too Many Replicas**: Set replicas to 10 for small service. Result: cost, complexity, no benefit. **Guard**: Calculate required capacity; auto-scale based on CPU/memory, not arbitrary numbers.39- **Health Checks Too Strict**: Fail readiness on any non-200 response. Result: cascading failures, thrashing restarts. **Guard**: Design probes to be lenient on transient errors; only fail on persistent issues.40- **No Graceful Shutdown**: Kill processes immediately. Result: in-flight requests dropped. **Guard**: Drain connections; wait for graceful shutdown before kill.41- **Ignoring Service Mesh Complexity**: Add service mesh (Istio) for features you don't need. Result: operational overhead, debugging difficulty. **Guard**: Start simple; add mesh when you need advanced features (traffic splitting, security policies).4243## Further Reading4445- _Kubernetes in Action_ by Marko Luksa — Kubernetes deployment patterns46- _Site Reliability Engineering_ by Google — production deployment practices47- _The Phoenix Project_ by Gene Kim — deployment culture and practices
sethdford