In part 8 of our System Design series, we’ll explore the practices and patterns that help systems evolve, stay resilient, and simplify operations over time.
We’ll cover:
- Service Discovery – Dynamic endpoints, central config
- Deployment Strategies – Canary, blue/green, rollbacks
- Monolith vs Microservices – Split only if ops cost justified
- Distributed Transactions – Use sagas, avoid 2PC
- Event Sourcing & CQRS – Append-only logs, splitting models
1. Service Discovery
TL;DR: Don’t hardcode service endpoints; let services find each other dynamically.
- Central Registry (e.g., Consul, Eureka): Services register and clients query the registry.
- Client-side Discovery: Clients load balance by querying registry.
- Server-side Discovery: Load balancer handles discovery logic.
👉 Example: Kubernetes services use DNS and service mesh proxies (e.g., Envoy).
👉 Interview tie-in: "How does a service find other services in a dynamic environment?" — Central registry approach.
2. Deployment Strategies
TL;DR: Minimize risk during releases.
- Blue/Green Deployment: Deploy to parallel environment, then switch traffic.
- Canary Deployment: Gradually expose new version to a subset of users.
- Rollbacks: Always have a plan to revert to stable version.
👉 Example: New feature rolled out to 5% of users first, monitor errors, then full rollout.
👉 Interview tie-in: "How do you minimize deployment risk in production?" — Canary or blue/green deployment.
3. Monolith vs Microservices
TL;DR: Don’t microservice just because it sounds trendy.
- Monolith: Simple to develop but harder to scale as code grows.
- Microservices: Independent scaling and deployments but added complexity.
👉 Example: Start monolithic, split when ops bottlenecks emerge.
👉 Interview tie-in: "When would you split a monolith?" — Ops complexity or team size grows.
4. Distributed Transactions
TL;DR: Avoid 2PC; prefer sagas.
- 2PC (Two-Phase Commit): Strong consistency, high latency.
- Sagas: Local transactions with compensating actions.
👉 Example: Order triggers inventory decrement and payment; if payment fails, inventory rollback occurs.
👉 Interview tie-in: "How do you handle cross-service transactions?" — Sagas.
5. Event Sourcing & CQRS
TL;DR: Append-only logs with separate read/write models.
- Event Sourcing: Store all events immutably.
- CQRS: Separate models for reads and writes.
👉 Example: Event store keeps actions history; read model serves queries.
👉 Interview tie-in: "Why use Event Sourcing over CRUD?" — Auditability and state rebuilds.
✅ Takeaways
- Use service discovery for dynamic environments
- Deploy safely with blue/green or canary strategies
- Microservices make sense only if ops cost justified
- Implement sagas over 2PC for distributed transactions
- Use Event Sourcing & CQRS when audit and performance matter
💡 Practice Question:
"Design a booking system where inventory, payment, and notification services coordinate. How do you ensure eventual consistency without 2PC?"
Top comments (0)