System Foundations

A client is a program that asks for a service, while a server is a program that waits for requests and provides that service. A browser can be a client, but so can a mobile app or a command-line tool. The words describe roles in one interaction, not fixed kinds of machines. One program may be a server to a browser and a client when it calls another service.

This separation exists so users do not need to store every application's data and rules on their own devices. Step by step, the client opens a network connection, sends a request containing what it wants, and waits. The server reads the request, runs the relevant logic, and returns a response. The response carries a result or an error, after which the connection may close or be reused.

For example, a weather app requests the forecast for a city. Its request identifies the city and the desired operation. The server looks up forecast data and responds with structured values that the app renders. In practice, developers should identify the client and server at every boundary, record enough request context to diagnose failures, and design both success and error responses deliberately.

The Domain Name System, or DNS, maps names such as api.example.com to network addresses. People and applications can keep using a stable name even when the server address changes. DNS exists because remembering addresses is inconvenient and tying a product directly to one machine makes migration and recovery difficult.

A lookup usually happens in stages. The client checks its local cache, then asks a recursive resolver, often operated by a network provider. If the resolver has no cached answer, it follows referrals through DNS authorities until it reaches the records for the domain. It returns the answer with a time to live, or TTL, which says how long the answer may be cached.

Suppose api.example.com has an A record pointing to 203.0.113.10. A browser resolves the name, caches the answer for its TTL, and then connects to that address. Practically, teams should lower TTL before a planned migration, verify records from more than one resolver, and remember that cached old answers make DNS changes gradual rather than immediate.

HTTP is an application protocol for requests and responses. A request has a method, target, headers, and sometimes a body; a response has a status code, headers, and sometimes a body. The protocol gives independent clients and servers a shared vocabulary. For example, GET asks to read a resource, while a 404 response says the requested resource was not found.

HTTPS is HTTP sent through Transport Layer Security, or TLS. First, the client connects and starts a TLS handshake. The server presents a certificate that links its public key to the requested name. The client validates the certificate, both sides agree on temporary session keys, and subsequent HTTP bytes are encrypted and protected against modification. TLS secures transport; it does not decide whether an authenticated user may access a record.

A browser might send GET /orders/42 with an Accept header and receive 200 plus JSON. Without TLS, another party on the network could read or alter that exchange. In practice, use HTTPS everywhere, avoid putting secrets in URLs where logs may capture them, select accurate status codes, and still perform authentication and authorization inside the application.

An application server is a running program that receives requests and executes product rules. An API is the contract through which another program asks it to do work. The contract names operations, inputs, outputs, and errors. This boundary exists so callers can use a capability without knowing the server's internal classes, database layout, or programming language.

When a request arrives, a router matches its method and path to a handler. Middleware may authenticate the caller, parse input, and attach shared context. The handler validates business input, calls domain or storage code, and maps the result into an API response. A final error layer converts known failures into stable error shapes and logs unexpected failures for investigation.

For example, POST /tasks may accept a title. The server authenticates the user, rejects an empty title, stores a new task, and returns 201 with the created task. Practical API design means documenting the contract, validating at the boundary, keeping handlers focused, and changing responses compatibly because clients may deploy on a different schedule.

State is information remembered across interactions, such as an account balance, shopping cart, or login session. A stateless request handler does not depend on private memory left by an earlier request. State is necessary for useful products, while stateless handlers are valuable because any equivalent server instance can process the next request.

In a stateless design, each request carries the identity and context needed to process it, and shared or durable state lives in an external store. A load balancer can therefore send consecutive requests to different instances. If a process stops, another instance reads the same durable facts and continues. Stateless does not mean the whole system has no state; it means request-serving processes do not own irreplaceable conversational state.

For example, an API instance validates a signed session token and loads a cart from a shared database. A second instance can handle checkout without seeing the first process's memory. In practice, locate each important piece of state, choose its owner and lifetime, avoid relying on local memory for correctness, and make temporary caches safe to lose.

End-to-end tracing follows one request from the client through each component and back. It exists because a user sees one action while the system performs many steps. Looking at only one server can miss delays in name resolution, connection setup, downstream APIs, storage, or the client itself. A shared request or trace identifier ties evidence together.

Begin when the user acts and note the exact time. Follow DNS resolution, connection establishment, the TLS handshake, and the outgoing HTTP request. At the edge and application server, find logs with the same identifier, then inspect downstream calls and storage work. Finally, match the response status and timing to what the client received and rendered. Record duration at each boundary instead of guessing.

Imagine checkout takes four seconds. The browser timing shows a fast connection but a long wait for response bytes. The application trace shows most time inside a payment API call, while database work is quick. The practical action is to address that dependency with an appropriate timeout or product flow, not to optimize unrelated queries. Trace representative failures while protecting secrets and personal data in logs.