Design and Operate a Monolith on Kubernetes
Context
You are joining an infrastructure team. The backend is a single monolithic service. The company is not pursuing microservices or aggressive horizontal scaling right now. Assume:
-
Moderate scale (e.g., peak 2–5k RPS), high availability target across multiple zones, zero-downtime deploys.
-
Single cloud provider with managed Kubernetes, managed databases/caches/object storage where possible.
-
Mix of web (HTTP), background workers, and scheduled jobs from the same monolith codebase.
Task
Design how you would run this monolith on Kubernetes. Cover:
-
Deployment topology
-
Pods, replicas, separation of web vs worker vs cron jobs
-
Node pools, placement, disruption policies
-
Networking and traffic management
-
Services, Ingress, TLS, rate limiting, canary traffic splitting
-
Configuration and secret management
-
Configs, secrets, rotation, feature flags
-
CI/CD and rollout strategies
-
Pipelines, blue/green vs canary, automated rollback
-
Resource management and autoscaling
-
Requests/limits, HPA/VPA, cluster autoscaling, capacity buffers
-
Handling stateful dependencies
-
Databases, caches, object storage, migrations, connections
-
Observability
-
Logs, metrics, traces, SLOs, alerting
-
Incident response
-
Runbooks, on-call, kill switches, rollback
-
Disaster recovery and backups
-
RTO/RPO targets, backups, restore drills
-
Architecture trade-offs
-
Monolith vs microservices, concrete signals that justify a change, and a low-risk, incremental migration path (service boundaries, data ownership, API contracts, team workflows)