🖥️ Application

The layer users interact with and where business value is delivered. Frontend presentation, backend logic, mobile experiences, and the architectural patterns that shape how applications are structured, deployed, and scaled.

🎨

Frontend / Presentation

What users see and interact with

Single Page Application (SPA)

React, Angular, Vue, Svelte

Loads once and dynamically updates the page without full reloads. JavaScript framework manages state and rendering in the browser. Feels fast and responsive. Communicates with backends exclusively via APIs.

🏛️ Context: SPAs shift rendering to the client, reducing server load but increasing frontend complexity. SEO and initial load time are trade-offs — mitigate with SSR (Next.js, Nuxt) or static generation.

Server-Side Rendering (SSR)

Next.js, Nuxt, Remix, SvelteKit

HTML is generated on the server per request and sent to the browser ready-to-render. Combines the interactivity of SPAs with fast initial loads and SEO. The server does the heavy lifting on first paint.

🏛️ Context: SSR is the modern default for content-heavy sites. Adds server compute cost per request. Streaming SSR (React 18+) sends HTML progressively, improving perceived performance.

Static Site Generation (SSG)

Gatsby, Hugo, Astro, 11ty, Jamstack

Pages are pre-built at build time into static HTML. Served from a CDN with zero server compute at request time. Extremely fast, secure, and cheap to host. Best for content that doesn't change per-user.

🏛️ Context: SSG + CDN delivers the best performance and lowest cost for marketing sites, documentation, and blogs. ISR (Incremental Static Regeneration) bridges SSG and SSR for dynamic content.

Micro-Frontends

Module Federation, Single-SPA, iframes

Breaking a frontend monolith into independently developed, deployed, and owned pieces — one per team or domain. Composed at runtime into a single user experience. The microservices idea applied to the UI.

🏛️ Context: Justified at scale (5+ teams on one frontend). Webpack Module Federation is the leading approach. Trade-offs: shared dependency management, consistent UX, and performance overhead of composition.

Design System

Component library, Storybook, Figma tokens

A shared library of reusable UI components, design tokens (colours, spacing, typography), and patterns. Ensures visual consistency across applications and accelerates development by eliminating redundant UI work.

🏛️ Context: A design system is a platform capability. Invest in it as a product with its own team, versioning, documentation (Storybook), and adoption metrics. Reduces UI inconsistency and duplicated effort at scale.

⚙️

Backend / Business Logic

Where business rules and data processing live

Monolith

Modular monolith, Majestic monolith

A single deployable unit containing all business logic, data access, and APIs. Not a dirty word — most successful systems start here. A well-structured "modular monolith" enforces boundaries without distributed system complexity.

🏛️ Context: Start monolith, extract microservices when specific scaling or team autonomy needs arise. A modular monolith with clean domain boundaries can evolve to microservices later with lower risk.

Microservices

Bounded contexts, Service mesh, DDD

Independent services, each owning a domain and its data. Deployed, scaled, and developed independently. Communication via APIs or events. Enables team autonomy and independent scaling at the cost of operational complexity.

🏛️ Context: Microservices are an organisational scaling pattern as much as a technical one. Align boundaries to domains (DDD bounded contexts) and teams (inverse Conway). Require mature CI/CD, observability, and service mesh.

Serverless Functions

Lambda, Cloud Functions, Azure Functions

Event-driven code execution where the cloud provider manages all infrastructure. Pay per invocation, scale to zero, and scale to millions automatically. Ideal for glue logic, webhooks, scheduled jobs, and event processors.

🏛️ Context: Serverless excels for event-driven, spiky, or low-traffic workloads. Cold starts and execution time limits are real constraints. For complex applications, combine serverless with containers — each where they fit best.

Backend-for-Frontend (BFF)

BFF pattern, API aggregation layer

A dedicated backend per frontend type (web, mobile, TV). The BFF aggregates, transforms, and optimises API responses for its specific client's needs. Prevents one-size-fits-all API bloat.

🏛️ Context: BFF is powerful when web and mobile have significantly different data needs. Avoids mobile fetching desktop-shaped responses. Each frontend team owns their BFF, reducing cross-team dependencies.

CQRS / Event Sourcing

Command Query Responsibility Segregation

CQRS: separate models for reading and writing data, optimised independently. Event Sourcing: store every state change as an immutable event, reconstruct current state by replaying events. Powerful for audit trails and temporal queries.

🏛️ Context: CQRS adds complexity — apply selectively to domains that benefit (high read:write ratio, complex queries). Event Sourcing provides perfect audit trails but requires careful event schema evolution and projection management.

📱

Mobile & Multi-Platform

Reaching users on every device

Native Mobile

Swift/SwiftUI (iOS), Kotlin/Jetpack Compose (Android)

Platform-specific development using Apple and Google's official languages and frameworks. Maximum access to device capabilities (camera, sensors, notifications), best performance, and native look-and-feel.

🏛️ Context: Native is justified when device capabilities, performance, or platform-specific UX are critical. Doubles the codebase and team — evaluate whether the trade-off is justified for your use case.

Cross-Platform

React Native, Flutter, Kotlin Multiplatform, MAUI

One codebase, multiple platforms. React Native uses JavaScript and native components. Flutter uses Dart and its own rendering engine. Kotlin Multiplatform shares business logic while keeping native UIs.

🏛️ Context: Cross-platform saves ~40% development cost at some native fidelity trade-off. Flutter has the richest cross-platform story (mobile + web + desktop). React Native leverages existing web/JS talent.

Progressive Web App (PWA)

Service workers, Web manifest, Offline-first

A website with native app capabilities: installable on home screen, works offline via service workers, push notifications, and access to some device APIs. Distributed via URL — no app store needed.

🏛️ Context: PWAs eliminate app store friction and reach all platforms from one codebase. Limitations: no full device API access (especially on iOS), and discoverability depends on web traffic vs. store search.

Desktop Applications

Electron, Tauri, WPF, SwiftUI (macOS)

Applications running natively on desktop operating systems. Electron wraps web tech in a Chromium shell (VS Code, Slack). Tauri uses the OS webview for smaller, faster alternatives. Native frameworks for platform integration.

🏛️ Context: Electron is ubiquitous but resource-heavy. Tauri offers smaller binaries and lower memory. For enterprise internal tools, consider whether a PWA or web app eliminates the need for desktop deployment entirely.

🧪

Quality & Testing

Ensuring applications work correctly at every level

Unit Testing

Jest, JUnit, pytest, xUnit

Testing individual functions or components in isolation. Fast, cheap, and numerous. The base of the testing pyramid. Validates that business logic works correctly at the smallest granularity.

🏛️ Context: Target 80%+ code coverage for business logic. Unit tests should run in milliseconds and execute in CI on every commit. Avoid testing implementation details — test behaviour and contracts.

Integration Testing

API testing, Contract testing, Pact, Testcontainers

Testing how components work together — API endpoints, database queries, service interactions. Contract testing (Pact) verifies that producers and consumers agree on API shape without needing both running.

🏛️ Context: Contract tests are essential in microservices — they catch breaking API changes before deployment. Testcontainers spins up real dependencies (databases, queues) in Docker for realistic integration tests.

E2E / UI Testing

Playwright, Cypress, Selenium

Testing the full application from the user's perspective — browser automation that clicks buttons, fills forms, and verifies outcomes. Slow and brittle but validates real user workflows end-to-end.

🏛️ Context: Keep E2E tests focused on critical user journeys (login, checkout, core workflow). Playwright is the modern standard. Run in CI against staging environments. Flaky tests erode trust — invest in stability.

Performance & Load Testing

k6, JMeter, Gatling, Locust

Simulating realistic and extreme traffic to validate that the system meets performance requirements. Identifies bottlenecks, breaking points, and capacity limits before real users find them.

🏛️ Context: Performance test in production-like environments with production-like data. Define SLOs (p99 latency, throughput) and make them part of the CI/CD gate. k6 is developer-friendly and scriptable.

Application Architecture Patterns

Layered (N-Tier)

Presentation → Business Logic → Data Access → Database. The classic pattern. Simple and well-understood but can lead to tight coupling between layers. Good starting point for most applications.

Hexagonal (Ports & Adapters)

Business logic at the centre, adapters for external systems around it. The core domain has no dependencies on infrastructure — databases, APIs, and UIs are all pluggable adapters. Enables testability and flexibility.

Domain-Driven Design (DDD)

Model software around the business domain. Bounded contexts define clear ownership. Ubiquitous language aligns tech and business teams. Strategic for complex domains; overkill for CRUD applications.

Event-Driven Architecture

Systems communicate through events rather than direct calls. Highly decoupled, scalable, and resilient. Introduces eventual consistency. Requires robust event infrastructure and careful event design.

12-Factor App

Twelve principles for building cloud-native applications: externalised config, stateless processes, disposability, backing services as attachments, dev/prod parity, and more. The foundation for containerised, scalable apps.

Cell-Based Architecture

Divides the system into independent cells (self-contained units with own compute, data, and routing). Blast radius is limited to a single cell. Used by hyperscalers (AWS) for extreme resilience.

How Application Connects

⬇️

Application → Integration (Layer 6): Applications consume and expose APIs. Backend services communicate via message queues, events, and gRPC. Integration patterns shape application boundaries.

💾

Application → Data (Layer 3): Applications read from and write to databases, caches, and data stores. The data model is driven by application domain needs and access patterns.

🔄

Application ↔ Cloud/DevOps (Layer 4): CI/CD deploys applications. Containers package them. Observability monitors them. The application is designed for the deployment environment.

👤

Application → Users: This is the layer users touch. UX decisions, performance, accessibility, and reliability here directly determine business outcomes and user satisfaction.