Patterns Are Decisions Frozen in Code
Architecture patterns encode assumptions about scale, team structure, failure tolerance, governance, and change velocity.
This page focuses on when patterns work, when they break, and why many organizations struggle after copying them blindly.
“Most architecture failures are not technical — they are decision failures made too early.”
— Viswa
— Viswa
🏢 Layered Architecture
Simple, predictable, and easy to govern.
- Pros: Clear separation, easy onboarding, predictable.
- Cons: Rigid, cross-layer dependencies cause fragility.
- Example: Banking apps with presentation, business, data layers.
🧱 Modular Monolith
Strong internal boundaries with shared deployment.
- Pros: Easier team coordination, simpler deployment than microservices.
- Cons: Can become monolithic over time if modules are not well-structured.
- Example: Growing SaaS apps before splitting into microservices.
🔗 Microservices
Independent scaling and deployment.
- Pros: Flexible, independent team scaling.
- Cons: Operational complexity, requires monitoring and CI/CD maturity.
- Example: E-commerce platform with separate services for cart, payment, catalog.
📡 Event-Driven Architecture
Loose coupling and async flows.
- Pros: Responsive, decoupled services, scalable events.
- Cons: Hard to debug, needs strong schema governance.
- Example: Real-time notifications, order processing systems.
📊 CQRS
Separate read and write models for scale.
- Pros: Optimized read/write paths, scalability for complex domains.
- Cons: Higher cognitive load and infrastructure complexity.
- Example: Inventory management systems with high read/write traffic.
🌐 Data Mesh
Decentralized data ownership.
- Pros: Domain-oriented, scalable data product approach.
- Cons: Needs strong platform support and governance discipline.
- Example: Large enterprises with multiple business units owning datasets.
“A pattern is only successful if the organization can sustain it.”
— Viswa
— Viswa