Web application architectures

A fictional ticket app lets you choose a seat, pay, and receive an email. The page makes these steps look like one activity, but several components cooperate. Understanding their responsibilities makes security decisions easier to locate.

Three responsibilities, many deployments

The Front end presents information and collects input. The Back end handles application decisions. A data layer stores or retrieves information. These are useful logical roles, not a law that every app must use three machines.

Server-rendered pages, single-page applications, and mobile clients distribute presentation work differently. A small service may combine application and storage on one host. A larger system may use queues, caches, managed databases, and many workers. Draw actual data flows rather than forcing every system into the same picture.

An API defines operations that other software can request. HTTP is common for web APIs, but “API” is a broader idea than HTTP, and an endpoint is not automatically public just because it exists.

Client checks help users; services enforce rules

A browser can reject an empty form quickly or disable a sold-out seat. Those checks improve usability. The receiving service must still validate the request, calculate authoritative prices, and decide whether this account may reserve or cancel that booking.

A Trust boundary appears wherever one component accepts information or authority from another. The browser-to-service boundary matters, but so do service-to-service calls, incoming payment notifications, and background jobs. A component being “internal” does not remove the need to check what it is allowed to request.

The page displays the right price. Is the purchase safe?

The ticket service must obtain the authoritative price and verify availability when committing the booking. A correct display is useful, but it cannot establish the validity of the final transaction. Concurrent purchases also require consistency controls.

The same language can have different authority

JavaScript can run in a browser or in a server runtime such as Node.js. What matters is the execution environment, identities, available APIs, and data access. Server code should protect service credentials. Browser code also deserves careful protection: a shared script flaw may affect many users and their authenticated actions, not just one visitor.

Some managed data platforms intentionally expose APIs directly to browser clients. Their safety depends on enforced service-side rules, correctly scoped identities, and appropriate public configuration. Administrative secrets do not belong in downloaded client code.

Follow work after the request ends

The email worker may need a recipient and booking reference, not payment credentials or unrestricted database access. Give queues, caches, and workers their own policy and ownership. Define retry behavior so a repeated request does not create a duplicate charge. Continue with object authorization and workload identities to examine these boundaries in small steps.

Follow a booking across time

At 10:00, Maya and Leo both see seat B4 available. At 10:01, Maya confirms first. At 10:02, Leo’s page still shows the earlier state. The service must decide using authoritative availability when it commits the operation; a stale display must not create a second valid claim. Transactions, constraints, or other concurrency controls coordinate the state change. The architecture needs to identify which component owns that guarantee.

If Maya’s connection drops after confirmation, the service may already have saved her booking. A retry policy must account for this uncertain result. A spinner timing out is evidence about the client’s experience, not proof that no transaction occurred. Well-designed recovery lets the client discover the result without blindly creating another operation.

State travels across boundaries

The session connects requests to an authenticated context. The booking record represents the durable purchase. A cookie may carry a session identifier, while a database stores the booking and a queue stores pending email work. They are related but have different lifetimes and permissions. Ending a session should not accidentally erase a completed purchase; deleting a cookie should not be mistaken for deleting the server’s session record.

TLS can protect browser-to-edge communication, while a second protected connection reaches the origin. If an intermediary terminates TLS, it becomes part of the trust story because it can access the decrypted content. Protect each relevant connection and still enforce application permissions at the point where an action is approved.

PredictThe booking page uses HTTPS and displays Maya’s name. Does that prove a cancellation request can affect only her bookings?

No. The protected channel and displayed identity do not establish object-level authorization. The receiving service must connect the current session, the requested booking, and the permitted cancellation policy.

Continue with from click to response and state, cookies, and sessions to follow these mechanisms step by step.