Application Architecture by Use Case
Architecture that adapts to what you are building — not what is fashionable. Context-aware decisions, not organisational habit.
Why "One Architecture Fits All" Fails
Organisations standardise on a single architecture pattern, a single stack, or a single deployment model and force every product into it. This leads to over-engineered simple systems, under-controlled critical systems, unnecessary cost, poor developer experience, and fragile operations.
Clavon avoids this by anchoring architecture decisions to use case characteristics, not organisational habit.
Selection CriteriaArchitecture Selection Matrix
Before selecting an architecture, we classify the application across these axes:
User Profile
External users, internal users, or both?
Interaction Style
Read-heavy, write-heavy, real-time, batch?
Data Sensitivity
Regulated, financial, personal, low-risk?
Change Frequency
Daily iteration or quarterly releases?
Scale Driver
Users, transactions, data volume, integrations?
Integration Density
Few integrations or many upstream/downstream systems?
Failure Impact
Inconvenient, costly, or catastrophic?
Architecture by Use Case
Six distinct application contexts, each demanding a different architectural approach.
Web Applications
Characteristics
- -Browser-based access
- -Mix of read/write operations
- -High UX expectations
- -Variable traffic patterns
Recommended Architecture
Modular monolith (default) with clear domain modules, BFF where UX complexity justifies it, REST APIs for client communication.
Common Failure Modes
- -Premature microservices
- -UI logic leaking into backend
- -Overuse of synchronous integrations
- -No performance budget
Clavon guidance: Optimize for change speed first. Introduce async patterns only when justified.
Mobile Application Backends
Characteristics
- -Mobile clients are unreliable (networks, latency)
- -API contracts must be stable
- -Backward compatibility is critical
- -Auth and authorization are central
Recommended Architecture
API-first backend with clear versioning strategy, stateless services, modular monolith or microservices depending on team maturity.
Common Failure Modes
- -Breaking API changes
- -Chatty APIs that drain battery
- -Overloaded endpoints
- -Poor error semantics
Clavon guidance: Mobile clients move slower than servers. Backends must be conservative and backward-compatible.
SaaS Platforms
Characteristics
- -Multiple customers share infrastructure
- -Strong isolation requirements
- -Subscription, billing, entitlements
- -Long-lived data
- -High availability expectations
Recommended Architecture
Modular monolith or carefully designed microservices. Key decisions: tenant isolation model, data partitioning strategy, configuration vs customization boundaries.
Common Failure Modes
- -Tenant data leakage
- -Hard-coded tenant assumptions
- -Over-customisation per customer
- -Billing logic scattered across services
Clavon guidance: Treat multi-tenancy as a core domain. Design isolation explicitly. Plan migration paths between isolation levels.
Enterprise Internal Systems
Characteristics
- -Complex workflows
- -Many user roles
- -Heavy ERP/CRM integration
- -Compliance and audit requirements
- -Predictable but critical usage
Recommended Architecture
Modular monolith with strong boundaries, explicit workflow orchestration, integration layer abstracting ERP/CRM dependencies.
Common Failure Modes
- -Business logic embedded in integrations
- -Tight coupling to ERP schemas
- -Poor test coverage for workflows
- -No ownership clarity
Clavon guidance: Internal systems should reduce complexity, not mirror it.
API-First & Integration-Centric
Characteristics
- -No UI or thin UI
- -Heavy upstream/downstream dependencies
- -Contract stability is critical
- -Failures cascade quickly
Recommended Architecture
API gateway + core services, strict contract governance, async events for state changes, synchronous APIs for commands.
Common Failure Modes
- -No versioning strategy
- -Shared databases
- -Hidden coupling via payloads
- -Poor observability
Clavon guidance: APIs are products. They require ownership, documentation, and lifecycle management.
Data-Intensive & Analytics-Driven
Characteristics
- -Large volumes of data
- -Batch and streaming workloads
- -Complex transformations
- -Downstream AI or reporting consumers
Recommended Architecture
Separate transactional and analytical paths, event or CDC-based data ingestion, clear lineage and ownership, scalable storage and compute separation.
Common Failure Modes
- -Analytics impacting transactional performance
- -Unclear data ownership
- -Manual data fixes
- -No monitoring of data quality
Clavon guidance: Never mix operational workloads and analytics without strong boundaries.
Decisions That Apply Across All Use Cases
Authentication & Authorization
- Centralised identity
- Context-aware authorization
- Token scopes and claims
- Explicit service-to-service trust
Error Handling & Resilience
- Timeouts and retries defined explicitly
- Circuit breakers for integrations
- Graceful degradation strategies
- User-visible vs internal error separation
Observability
- Logs, metrics, and traces per use case
- Business-level events captured
- SLIs aligned to user impact
Architecture Evolution Triggers
Common Anti-Patterns Eliminated
Reusing the same architecture blindly across different use cases
Designing for hypothetical future scale before the problem is real
Overusing async patterns where synchronous is simpler
Ignoring operational reality during design
Treating architecture as done rather than continuously evolved
Deliverables
Use-case-specific reference architectures
Decision rationale per application type
Integration and scaling strategies
Quality and operability implications
Architecture evolution roadmap with triggers