This content originally appeared on DEV Community and was authored by Sibasish Mohanty
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?"
This content originally appeared on DEV Community and was authored by Sibasish Mohanty
Sibasish Mohanty | Sciencx (2025-09-15T07:48:09+00:00) From Deployment to Architecture: Designing for Change and Scale. Retrieved from https://www.scien.cx/2025/09/15/from-deployment-to-architecture-designing-for-change-and-scale/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.