DevOps & System Design
CI/CD & Docker
1. What is CI/CD?
CI (Continuous Integration) — automates building and testing on every commit.
CD (Continuous Delivery/Deployment) — automates deployment to environments after tests pass.
2. GitHub Actions
Workflow automation using YAML files in .github/workflows/. Triggers: push, pull_request, schedule, manual dispatch.
3. Blue-Green Deployment
Maintains two identical environments (Blue = current, Green = new). Traffic switches to Green after validation. Instant rollback by switching back to Blue.
4. Canary Deployment
Gradually shifts a small percentage of traffic (e.g., 5%) to a new version before full rollout. Limits blast radius if the new version has issues.
5. Rollback Strategy
Restore the previous stable version when validation fails. Use immutable tags (semantic versions or commit SHAs) — never latest in production.
6. Describe a CI/CD pipeline you built (e.g., using Docker and Jenkins/GitHub Actions).
Experience-based question. Prepare to discuss:
- The stages of your pipeline (Build, Test, Push to Registry, Deploy)
- How you handled environment variables and secrets securely
- Integration with Docker and ECR
- How deployments were triggered (manual vs automated)
7. Docker: ENTRYPOINT vs CMD
ENTRYPOINT — fixed executable that always runs.
CMD — default arguments for ENTRYPOINT. Can be overridden at docker run.
8. Multi-stage Docker build
Reduces final image size by excluding build-time dependencies.
FROM python:3.11 AS builder
RUN pip install --user -r requirements.txt
FROM python:3.11-slim
COPY --from=builder /root/.local /root/.local
COPY . .
CMD ["python", "app.py"]9. Docker networking modes
bridge — default, isolated network between containers.
host — container shares the host’s network stack.
none — no networking.
System Design
For a senior role: questions are typically 45-60 minutes of discussion. Focus on thought process, scalability considerations, and trade-offs — not FAANG-level complexity.
10. How do you design a scalable ETL pipeline?
Source Systems
→ S3 Landing Bucket
→ Airflow Scheduler
→ Glue / Python / Spark
→ Data Validation
→ Snowflake / Redshift
→ BI / APIs
Key points: separate ingestion and transformation · store raw data first · idempotent pipelines · partition data · retry failed jobs · monitor with CloudWatch.
11. How would you process 700 million records?
- Partition files by date/entity
- Process in parallel (ECS, Spark)
- Use Parquet (not CSV)
- Process incrementally — not as one job
- Auto-scale compute
- Retry failed partitions only
12. How do you design a REST API?
- Resource-based URLs (
GET /users,POST /users,PUT /users/{id}) - Stateless
- Authentication (JWT/OAuth2)
- Pagination and filtering
- Versioning (
/v1/...) - Proper HTTP status codes
- Structured logging
13. How do you make APIs scalable?
- Load Balancer in front of stateless services
- Horizontal scaling
- Caching (Redis for repeated reads)
- Database indexing
- Async processing for long tasks
- Connection pooling
14. How do you design a file upload service?
Client → API (generate pre-signed S3 URL)
→ Client uploads directly to S3
→ S3 triggers EventBridge
→ Lambda/ECS processes the file
Benefits: no API bottleneck, supports large files, serverless upload, secure.
15. Design an image processing pipeline
Upload → S3 → SQS Queue → ECS Workers → Resize/AI → Processed Bucket
Parallel, retryable, scalable.
16. Design a Notification Service
Application → Message Queue → Notification Workers → Email / SMS / Push
Benefits: loose coupling, retry on failure, Dead Letter Queue for undeliverable messages.
17. Monolith vs Microservices
| Monolith | Microservices | |
|---|---|---|
| Deployment | Simple | Independent per service |
| Scaling | Scale entire app | Scale individual services |
| Debugging | Easier | More complex |
| Codebase | Single, can grow large | Smaller, focused services |
Start monolith, migrate to microservices when scaling pain is real — not prematurely.
18. REST vs GraphQL
REST — multiple endpoints, fixed response shape.
GraphQL — single endpoint, client specifies exact fields, reduces over-fetching.
19. REST vs gRPC
REST — JSON over HTTP, human-readable, widely supported.
gRPC — Protocol Buffers, faster, strongly typed. Better for internal service-to-service communication.
20. High Availability design
- Multi-AZ deployment
- Auto Scaling
- Load Balancer with health checks
- Database replication
- Route 53 failover
21. Fault Tolerance design
- Retries with exponential backoff
- Circuit Breaker (stops calling a failing service)
- Dead Letter Queue (stores unprocessable messages)
- Auto Recovery
- Monitoring and alerting
- Redundancy
22. Idempotency
Repeated execution produces the same result as running once. Critical for safe retries.
Example: running the same ETL job twice must not duplicate records. Use MERGE/UPSERT, or delete + reinsert by partition.
23. What is a Dead Letter Queue?
Stores messages/events that fail processing after all retry attempts. Prevents data loss and enables later inspection and reprocessing.
24. SQS vs Kafka
| SQS | Kafka | |
|---|---|---|
| Model | Queue | Log/stream |
| Replay | No | Yes |
| Throughput | High | Very high |
| Ops | Fully managed | Self-managed or MSK |
| Best for | Simple decoupling | Event streaming, replay |
25. Queue vs Pub/Sub
Queue — one consumer processes each message (point-to-point).
Pub/Sub — multiple subscribers receive the same message (broadcast). SNS, EventBridge.
26. API Gateway
Provides: authentication · routing · rate limiting · request/response transformation · monitoring · SSL termination.
27. Load Balancer
Distributes traffic across multiple instances to improve availability and performance.
ALB (L7) — routes by HTTP path/host. NLB (L4) — routes by TCP/IP. GLB — for network appliances.
28. Horizontal vs Vertical Scaling
Horizontal — add more servers. Preferred for cloud-native.
Vertical — increase CPU/RAM of one server. Has a hardware ceiling.
29. Caching
Temporarily storing frequently accessed data to reduce latency and database load.
Use for: API responses, DB query results, auth tokens, session data, static config.
30. Redis vs Database
Redis — in-memory, microsecond reads, temporary, used for caching and session storage.
Database — persistent, slower, source of truth.
31. Rate Limiting
Restricts requests a client can make within a time window. Protects services from abuse and runaway clients.
32. Database Connection Pooling
Reuses existing database connections instead of creating a new connection for every request, improving performance and reducing overhead.
33. Monitoring (what to track)
Key metrics to track:
- CPU and memory utilization
- API latency (p50, p95, p99)
- Error rates
- Queue depth
- Throughput (requests/sec)
- Database connection pool usage
- Data freshness (pipelines)
34. Logging Best Practices
- Structured logs (JSON format)
- Correlation IDs to trace requests across services
- Log levels: DEBUG, INFO, WARN, ERROR
- Never log secrets or PII
- Centralized logging (CloudWatch, ELK, Datadog)
35. Metrics vs Logs vs Traces
Metrics — numerical performance data (CPU%, latency).
Logs — detailed event records (what happened and when).
Traces — track a single request across multiple services (distributed tracing).
36. CAP Theorem
A distributed system can guarantee only two of three properties:
- Consistency
- Availability
- Partition Tolerance
Since network partitions are unavoidable, the real trade-off is between consistency and availability.
37. Event-Driven Architecture
Services communicate by publishing and consuming events instead of direct synchronous calls. Benefits: loose coupling, scalability, easier integration.
38. Circuit Breaker Pattern
Prevents repeated calls to a failing service. If failures exceed a threshold, the circuit “opens” and requests fail fast — giving the downstream service time to recover.
States: Closed (normal) → Open (failing fast) → Half-Open (testing recovery).
39. Bulkhead Pattern
Isolates resources (thread pools, connection pools) so a failure in one component doesn’t exhaust resources for the entire application.
40. Retry Pattern
Automatically retries transient failures with exponential backoff and jitter. Always combine with idempotency to avoid duplicate side effects.
41. Stateless vs Stateful Services
Stateless — no client session data on the server. Scales horizontally easily. Preferred.
Stateful — maintains session state. Requires sticky sessions or shared storage.
42. How do you secure a distributed application?
- HTTPS everywhere
- IAM/RBAC for authorization
- JWT or OAuth2 for authentication
- Encrypt data at rest and in transit
- Secrets Manager / Vault for credentials
- Input validation
- Audit logging
43. What do you consider first in any system design interview?
- Clarify functional requirements
- Identify non-functional requirements (scalability, availability, latency, security)
- Estimate scale (users, requests/sec, data volume)
- Design high-level architecture
- Discuss storage, APIs, caching, messaging, monitoring, and trade-offs
- Address bottlenecks and future scalability
Explain the architectural approach first, then map to specific technologies. Shows you understand design principles independently of any cloud platform.
44. How do you design a disaster recovery strategy?
- Cross-region backups
- Database replication (standby replica in secondary region)
- Infrastructure as Code (recreate infra from scratch if needed)
- Automated recovery procedures
- Regular DR drills
- Defined RPO (Recovery Point Objective) and RTO (Recovery Time Objective)