How to Choose a Web Application Architecture That Can Scale

Web application architecture describes how the browser, application logic, identity, data, integrations, and operations work together. Choose it from the workload and consequences of failure, then test those assumptions. More servers or more services do not automatically produce a faster, cheaper, or safer system.

For a founder, the useful output is a decision record: what the product must do, what it must protect, which failures it can tolerate, who will operate it, and what evidence would justify a change. Start with the simplest system that can meet those requirements.

Define the workload before selecting tools

Requirement	Write down	Why it changes the design
Workflow	Read-heavy content, transactional updates, collaboration, batch processing, or streaming	Determines request, job, and consistency patterns
Load	Peak concurrent activity, requests/jobs per second, payload size, and growth assumptions	User registrations alone do not establish capacity needs
Data	Sensitivity, tenancy, ownership, volume, retention, and transactional rules	Shapes authorization, storage, backup, and migration
Latency	Which user action needs which response time, at a stated percentile	Distinguishes slow dependencies from browser or database work
Availability	Which functions must remain usable, measurement window, and exclusions	Shapes redundancy, graceful degradation, and support
Recovery	Maximum tolerable downtime and data loss	Determines backup, replication, restore, and rollback work
Team	Skills, deployment ownership, and incident coverage	Constrains operational complexity
Cost	Implementation, infrastructure, data transfer, monitoring, support, and maintenance	Prevents a cheap compute choice from hiding expensive operations

For SaaS, add tenant-isolation and billing rules. For an internal tool, prioritize its systems of record and operator permissions. For public content, examine cacheability, rendering, and publishing workflow. None needs every possible component.

A web app is a client-server system

The browser is a client. Servers receive requests and perform work or return representations. Web systems may have many layers and tiers; “web” does not imply a separate category outside client-server architecture.

HTTP semantics describe a stateless protocol. That does not mean a server cannot store data, or that users must log in on every visit. Applications maintain state through databases, sessions, cookies, tokens, and other mechanisms. Authentication lifetime and session security are application decisions.

Caching reuses eligible responses or computed data to reduce repeated work. It is not the mechanism that makes login possible. Decide freshness, invalidation, and authorization boundaries explicitly; shared caches must not expose one user’s private response to another.

Separate architecture dimensions

Dimension	Options	Tradeoff
Rendering	Server-rendered pages, static generation, client-rendered SPA, or a mixture	Content freshness, browser JavaScript, interactivity, navigation, and crawlability
Application boundaries	Modular monolith or independently deployed services	Simpler coordination versus independent ownership and deployment
Interface	Internal calls, HTTP APIs, events, or a mixture	Coupling, versioning, latency, and failure handling
Data	Relational records, object storage, search index, cache, specialized stores	Consistency, access patterns, operational cost, and recovery
Deployment	Managed application platform, servers, containers, serverless functions	Control, service limits, scaling behavior, cost, and team burden

A single-page application can use a monolithic backend. A server-rendered application can call several services. Containers package runtime workloads; they are not a competing architecture category to microservices.

Three-tier designs separate presentation, application logic, and data responsibilities. Logical separation need not mean three independently operated machines. Changing an interface or data contract can still affect other layers; separation reduces some coupling but does not eliminate it.

Compare the main backend choices

Approach	Consider when	Costs and failure modes
Modular monolith	A small team owns a related set of workflows and needs simple deployment	Modules require discipline; shared release or resource contention can affect several workflows
Independent services	Distinct domains have stable boundaries and teams need independent delivery or capacity	Network failures, distributed tracing, data consistency, deployment coordination, and on-call ownership
Serverless functions	Work fits the provider’s execution model and variable or event-driven demand	Runtime limits, startup latency, quotas, dependency cost, and vendor-specific behavior
Long-running workers	Jobs require sustained processing, special runtime control, or predictable throughput	Capacity planning, worker failure, retries, and deployment management

Microservices should have clear data ownership. Directly sharing tables across services can undermine independent change and create coupling. Separate data stores require deliberate cross-service consistency and recovery; they do not make multi-step transactions automatically atomic.

Understand products without treating them as guarantees

AWS Lambda runs code with provider-managed infrastructure. Servers still exist, and application limits, dependencies, permissions, and costs remain the team’s concern. AWS Step Functions orchestrates workflows; it is not “built on API Gateway.” An API gateway handles configured API entry concerns such as routing or access integration, but application authorization still needs correct implementation.

Docker describes containers as isolated processes with the files needed to run. An image packages the application and dependencies, but compatibility still depends on runtime, operating-system kernel, CPU architecture, configuration, and external services. Containers do not guarantee identical behavior on every machine or automatically improve processing power.

A representative starting architecture

Consider a hypothetical B2B approvals application with a small engineering team, two pilot customers, ordinary form workflows, attachments, and email notifications. No clinical decision-making or payment execution is included.

Browser ──HTTPS──> application entry point ──> modular application
                                               │
                         identity provider <───┤
                                               ├──> relational database
                                               ├──> private object storage
                                               └──> durable job queue ──> worker ──> email provider

Application and workers ──> metrics, structured logs, and traces
Database and stored files ──> tested backup and recovery procedures

The application checks membership and permissions on every sensitive action. The database records workflow state and audit events. Store attachments privately and authorize downloads. Queue notifications so a slow email provider does not block saving the request. Use a durable handoff, such as a transactional outbox where appropriate, so committing a request and scheduling its notification cannot silently diverge.

Object storage holds files; it is not a replacement for transactional records. A CDN may cache public assets, while private content requires suitable access and cache rules. Neither object storage nor a CDN is mandatory for every app, and neither removes origin capacity or security responsibilities.

Specify failures and observations

Failure	Required behavior in the example	Evidence to observe
Duplicate submission	One intended request, or a clear duplicate response	Idempotency record and resulting database state
Email provider unavailable	Save the request, queue/retry notification, expose persistent failures	Queue age, retry count, failed-job alert
Unauthorized tenant access	Deny access without returning restricted content	Boundary tests and appropriately minimized security logs
Worker crashes	Recover work without repeating an unsafe side effect	Retry/recovery test and job state
Database unavailable	Clear failure or safe degraded behavior; no false success	Error rate, health signals, customer-visible status
Bad deployment or data change	Defined rollback or forward repair; verified data recovery	Rehearsal evidence and accountable release owner

Logs need context such as request or job identifiers without unnecessarily recording sensitive data. Monitor user-visible outcomes, not only CPU. A green infrastructure dashboard can coexist with failed approvals or missing notifications.

Add capacity from measured constraints

A load balancer distributes traffic according to configured routing and health behavior. Additional application instances can help only if the bottleneck is there and sessions, data, and dependencies support it. They can also increase database pressure. A CDN helps eligible content delivery; it does not fix slow writes or an unavailable database.

For the hypothetical approvals app, propose a p95 response target below 500 ms for ordinary API requests at 50 concurrent active users and a two-minute notification-delay target. These are example acceptance targets, not universal performance standards. Test representative payloads, failures, and a sustained load period.

If database queries dominate latency, inspect query plans, indexes, and contention before adding app servers. If notification queue age breaches the target, inspect provider limits and worker throughput before adding workers. If one domain repeatedly needs independent releases and has clear ownership and data boundaries, evaluate extracting it as a service. A growth forecast alone is not that evidence.

Validate and record the choice

Test throughout implementation, including authorization, integrations, load, restore, and deployment recovery. Testing cannot guarantee that production has no defects; it makes specific risks visible. Use QA methodology and technical discovery to organize the work.

For a new product, include these requirements when assessing Hapy’s MVP development service or another engineering proposal.

Keep a short architecture decision record with requirements, alternatives, the selected approach, known tradeoffs, cost assumptions, owner, and review trigger. Include baseline measurements and the conditions that would justify revisiting the decision. This makes architecture a maintainable business choice rather than a permanent bet on a fashionable tool.