Website Architecture Patterns

Architecture is the set of components, responsibilities, data flows, and failure boundaries that deliver the website. Choose the simplest pattern that meets the real goal.

Pattern 1: One Static Server

DNS -> Nginx -> Static files

Strengths

• Few components
• Easy to understand
• Small application attack surface
• Straightforward backup and rollback

Limits

• One server is one failure boundary.
• Content changes require deployment.
• Dynamic features need another component.

This pattern is suitable for learning, documentation, portfolios, and small informational sites when the availability requirement permits it.

Pattern 2: Reverse Proxy and Application

DNS -> Nginx -> Application -> Database

Strengths

• Supports accounts, forms, and dynamic data.
• Separates public TLS from the application listener.
• Can route static and dynamic paths differently.

Limits

• More credentials and updates
• Database backup and migration requirements
• More failure modes
• Application security responsibility

Pattern 3: Separate Static Frontend and API

www.example.dpdns.org -> Static frontend
api.example.dpdns.org -> API -> Database

This can separate deployment lifecycles, but browser security, cross-origin policy, cookies, tokens, and API availability become explicit design concerns.

Do not expose a privileged API merely because the frontend is static.

Pattern 4: Multiple Application Servers

DNS -> Load balancer -> App A
                     -> App B

Multiple servers improve availability only when state, health checks, deployments, certificates, dependencies, and failover are designed accordingly.

Two application servers behind one unmonitored database and one load balancer are not complete redundancy.

Stateful and Stateless Components

A stateless application can handle a request without relying on local session or uploaded data from a previous request. State may live in a database, object store, or shared cache.

Stateless design can make horizontal scaling easier, but the external state systems become critical dependencies.

Failure Domains

Ask what happens if each component fails:

• Registration account unavailable
• Authoritative DNS unavailable
• One network unavailable
• Server lost
• Certificate renewal fails
• Database corrupts
• Deployment publishes broken files
• Monitoring provider fails
• Operator loses credentials

Components are not independent when they share the same account, network, physical host, billing method, or recovery email.

Data Flow Diagram

For every dynamic site, draw:

User data
-> Browser
-> Public proxy
-> Application
-> Database
-> Logs
-> Backups

Label:

• Encryption boundaries
• Authentication decisions
• Personal data
• Retention
• Third-party transfers
• Administrative access

Choose with a Decision Record

Use a short architecture decision record:

# Decision: Static site on one server

## Context
The site publishes documentation and has no accounts.

## Decision
Serve version-controlled static files with Nginx.

## Consequences
- Simple deployment and backup
- No server-side forms
- One-server availability boundary

## Revisit When
The site needs authenticated or database-backed features.

Migration Without a Rewrite

Start simple but preserve boundaries:

• Keep domain and DNS ownership documented.
• Keep source in version control.
• Use stable public URLs.
• Separate content from secrets.
• Automate reproducible builds.
• Make backups independent of the server.
• Monitor user-visible outcomes.

These practices make a future architecture change safer without requiring premature complexity.

Architecture Exercise

Draw the architecture for:

1. A personal static portfolio.
2. A community event site with a contact form.
3. An authenticated dashboard with uploads.

For each, identify the smallest design, sensitive data, backup scope, and single largest failure risk.

Continue to Reliability and Capacity Planning.