Application Architectures

Selecting an application architecture is among the most consequential decisions in software development. The choice between monolithic, microservices, or hybrid approaches ripples through every aspect of the system—development velocity, operational complexity, team structure, cost, and ultimately, the product's ability to evolve and scale.

There is no universally "best" architecture. Each approach optimizes for different qualities, and the right choice depends on understanding your specific context: team size and expertise, product requirements, growth trajectory, and organizational constraints.

This page synthesizes the architectural patterns we've explored into a decision framework—providing the analytical tools to evaluate trade-offs, avoid common pitfalls, and make informed choices. Rather than prescribing answers, we'll develop the reasoning skills that enable sound architectural judgment.

The Central Question:

Given our requirements, constraints, team, and trajectory, which architectural approach maximizes our probability of success while minimizing unnecessary complexity and cost?

Answering this question requires honest assessment across multiple dimensions—technical, organizational, and strategic.

Architectural decisions must account for multiple interrelated factors. Understanding these factors—and their relative importance for your context—is the foundation of sound decision-making.

1. Team Size and Structure:

Team composition profoundly influences which architectures are viable:

2. Product Maturity:

3. Scale Requirements:

Different architectures handle scale differently:

┌─────────────────────────────────────────────────────────────────────────┐
│                    Scaling Characteristics                               │
│                                                                         │
│  Monolith:                                                              │
│  • Scale by adding instances behind load balancer                       │
│  • All components scale together (efficient if uniform load)            │
│  • Database often becomes bottleneck                                    │
│  • Practical limit: ~100-500 concurrent instances                       │
│                                                                         │
│  Microservices:                                                         │
│  • Scale services independently based on specific load                  │
│  • CPU-heavy service can scale differently from I/O-heavy               │
│  • Higher infrastructure overhead per request                           │
│  • More granular resource optimization possible                         │
│                                                                         │
│  Practical Question:                                                    │
│  Do different components have significantly different scaling needs?    │
│  If yes → Microservices may help                                        │
│  If no → Monolith scaling is simpler and sufficient                     │
└─────────────────────────────────────────────────────────────────────────┘

4. Deployment and Release Requirements:

5. Domain Complexity:

Microservices align with Domain-Driven Design's bounded contexts:

• High domain coupling: Components share data models → Monolith simpler
• Clear domain boundaries: Independent contexts → Microservices viable
• Evolving domain: Understanding still developing → Delay service extraction

Apply this systematic framework when evaluating architectural options:

Step 1: Identify Architectural Drivers

List the factors most critical to your system's success:

Step 2: Weight the Drivers

Not all factors matter equally. Assign weights based on your context:

Startup finding product-market fit:
  Modifiability: HIGH   (requirements change constantly)
  Deployability: MEDIUM (speed matters, but less critical)
  Scalability: LOW     (not yet a problem)
  Cost: HIGH           (limited runway)

Established e-commerce platform:
  Availability: HIGH   (downtime = lost revenue)
  Scalability: HIGH    (Black Friday traffic spikes)
  Modifiability: MEDIUM (stable core, new features)
  Cost: MEDIUM         (optimize, but reliability first)

Step 3: Evaluate Options Against Drivers

Score each architectural option against your weighted drivers:

Example scoring—your weights and scores will differ based on context.

Step 4: Consider Second-Order Effects

Beyond direct factors, consider ripple effects:

• Hiring: Do you have/can you hire distributed systems expertise?
• Tooling: What CI/CD, monitoring, orchestration investment is required?
• Cognitive Load: Can your team effectively reason about the system?
• Debugging: How will you troubleshoot production issues?
• Evolution: Can you change your mind later?

Step 5: Document the Decision

Use Architecture Decision Records (ADRs):

# ADR-001: Adopt Modular Monolith Architecture

## Status: Accepted

## Context
We're building a new e-commerce platform with a team of 12 engineers.
Initial traffic estimates are moderate (1000 req/sec peak).
Product requirements are evolving rapidly as we find market fit.

## Decision
We will build a modular monolith with clear domain boundaries.

## Consequences
+ Faster development velocity (single codebase, simple debugging)
+ Lower operational overhead (one deployment unit)
+ Clear path to extraction if scaling demands emerge
- Must enforce module boundaries through discipline/tooling
- All features scale together (acceptable for current scale)

Learn from the mistakes others have made. These anti-patterns recur across organizations attempting architectural transformations.

Architecture isn't static. As requirements, scale, and teams change, architecture must evolve. Plan for evolution from the beginning.

Monolith to Modular Monolith:

Phase 1: Identify Boundaries
├── Map domain contexts
├── Identify natural seams in code
└── Document dependencies between areas

Phase 2: Establish Modules
├── Create explicit module interfaces
├── Move shared code to common libraries
├── Enforce import rules (linting/build checks)
└── Separate database schemas per module

Phase 3: Validation
├── Each module can be tested independently
├── Changes in one module rarely affect others
└── Teams can work on modules with minimal coordination

Modular Monolith to Microservices:

Extract services incrementally, not all at once:

┌─────────────────────────────────────────────────────────────────────────┐
│                    Strangler Fig Pattern                                 │
│                                                                         │
│  Original Monolith                                                      │
│  ┌─────────────────────────────────┐                                    │
│  │   Feature A  │  Feature B  │  C │                                    │
│  └─────────────────────────────────┘                                    │
│                    │                                                    │
│                    ▼                                                    │
│  Step 1: Extract Feature A                                              │
│  ┌────────────┐  ┌─────────────────────┐                                │
│  │ Service A  │  │ Monolith (B + C)   │                                 │
│  └────────────┘  └─────────────────────┘                                │
│         │                │                                              │
│         └───── Facade routes traffic ────┘                              │
│                    │                                                    │
│                    ▼                                                    │
│  Step 2: Extract Feature B                                              │
│  ┌────────────┐  ┌────────────┐  ┌─────────┐                           │
│  │ Service A  │  │ Service B  │  │ Core (C)│                            │
│  └────────────┘  └────────────┘  └─────────┘                           │
└─────────────────────────────────────────────────────────────────────────┘

Based on the patterns and anti-patterns we've examined, here are practical recommendations for different scenarios:

For Startups (1-10 engineers):

✅ Start with a simple monolith ✅ Focus relentlessly on product, not architecture ✅ Use proven frameworks (Rails, Django, Express, Spring Boot) ✅ Deploy to simple infrastructure (PaaS like Heroku, Railway, or managed Kubernetes) ✅ Establish code quality practices early (testing, code review) ✅ Document major decisions for future reference

❌ Don't adopt microservices because it's trendy ❌ Don't over-engineer for scale you don't have ❌ Don't build custom infrastructure—use managed services

For Growth-Stage (10-50 engineers):

✅ Evolve toward a modular monolith with clear boundaries ✅ Invest in observability (logging, metrics, tracing) ✅ Implement CI/CD with automated testing ✅ Consider extracting specific services when justified ✅ Balance technical investments with product velocity ✅ Begin documenting architecture formally

❌ Don't extract services just to have microservices ❌ Don't ignore operational readiness when extracting ❌ Don't let module boundaries erode over time

For Scale-Stage (50+ engineers):

✅ Align services with team boundaries (inverse Conway maneuver) ✅ Invest heavily in platform capabilities (CI/CD, observability, service mesh) ✅ Establish architecture review processes ✅ Create internal platforms to reduce service overhead ✅ Maintain clear ownership for every component ✅ Document and communicate architectural principles

❌ Don't let every team create their own standards ❌ Don't ignore the platform/tooling team's needs ❌ Don't skip post-mortems and architectural learning

Universal Recommendations:

We've developed a comprehensive framework for architectural decision-making—understanding not just the technical trade-offs but the organizational, strategic, and evolutionary dimensions of architecture selection.

Module Completion:

With this page, we've completed our exploration of Application Architectures—from the foundational monolithic pattern through distributed microservices, web and mobile backends, to the decision frameworks that guide architectural choices.

You now possess the knowledge to:

• Evaluate architectural options systematically
• Understand trade-offs between simplicity and flexibility
• Recognize anti-patterns before they cause damage
• Plan evolutionary paths for growing systems
• Make and document sound architectural decisions

This knowledge forms the foundation for the remaining application layer topics—DNS, HTTP, email, and other protocols that implement the communication patterns these architectures require.