Session
A way to maintain state across multiple HTTP requests. The server stores data about a user and gives them a session ID (usually in a cookie).
What is Session?
In short
A session is server-side memory of a single user across multiple HTTP requests. Because HTTP forgets everything between requests, the server stores per-user data (like who is logged in) under a unique session ID, hands that ID to the browser in a cookie, and reads the ID back on every later request to recognize the same person.
What a session actually is
HTTP is stateless. Each request stands alone, and the server treats the second request from you exactly like the first, with no memory that you logged in five seconds ago. A session is the workaround. It is a bundle of data the server keeps about one user, identified by a single random string called the session ID.
Think of a coat check at a theater. You hand over your coat, you get a numbered ticket, and the theater keeps the coat. The ticket is small and means nothing on its own, but it lets the theater find your coat later. The session ID is the ticket; the actual data (user ID, cart contents, permissions) is the coat, sitting on the server.
The browser carries the ticket automatically. On login the server generates a session ID like 9f2a3c..., stores the real data against that key, and sends the ID back in a Set-Cookie header. The browser then attaches that cookie to every following request to the same site, so the server can look up who you are without asking you to log in again.
How it works under the hood
The flow is four steps. The user submits credentials, the server verifies them, the server creates a session record and a random ID, and the server returns the ID in a cookie marked HttpOnly so JavaScript cannot read it and Secure so it only travels over HTTPS. From then on the cookie rides along on each request and the server hydrates the user context from the stored record.
Where the session data lives matters a lot. Storing it in the web server process memory is fast but breaks the moment you run more than one server, because a request that lands on server B cannot find the session created on server A. The common fix is a shared store such as Redis or Memcached, which every server can reach. A typical Redis session lives under a key like sess:9f2a3c with a TTL of 30 minutes that resets on each request.
An alternative is to put the data inside the token itself instead of on the server. A signed JWT carries the user ID and expiry in the cookie, and the server only verifies the signature, holding nothing. That removes the lookup but makes instant logout harder, because a valid token stays valid until it expires unless you keep a blocklist, which quietly reintroduces server state.
When to use it and the trade-offs
Server-side sessions are the right default for classic web apps where a backend renders pages and you want to revoke access immediately. Banking dashboards and admin panels lean this way because you can kill a session the instant fraud is detected, just by deleting one Redis key.
The cost is that sessions are state, and state fights horizontal scaling. You either pin a user to one server with sticky sessions, which wastes capacity and dies when that server dies, or you run a shared store, which is one more system to operate, secure, and keep available. A Redis outage can log out every user at once.
Security is the other tax. A stolen session cookie is a stolen identity, so sessions need HttpOnly and Secure flags, the SameSite attribute to blunt CSRF, short expiry, and a fresh ID issued at login to prevent session fixation. Sliding expiry keeps active users logged in while idle sessions time out, usually somewhere between 15 minutes for sensitive apps and a few weeks for low-risk consumer sites.
A concrete example
Picture an online store at checkout. You add three items to a cart while logged out. The server creates a session, drops a sess_id cookie, and stores the cart against that ID in Redis. You browse five more pages, and each request carries the cookie, so the cart survives even though HTTP itself remembers nothing.
You log in. The server invalidates the anonymous session ID and issues a new one tied to your account, merging the guest cart into your saved cart. Issuing a new ID at the privilege change is the defense against session fixation, where an attacker plants a known ID before you authenticate.
You pay, close the tab, and come back an hour later. If the session TTL was 30 minutes, the Redis key has expired, the cart is gone from the session, and you start fresh, which is exactly the behavior most stores want for anonymous traffic while keeping logged-in carts in the database for longer.
Where it is used in production
Redis
The most common shared session store. Apps keep session data under keys like sess:ID with a TTL so idle sessions expire automatically across a fleet of servers.
PHP and WordPress
PHP's built-in session handler writes a PHPSESSID cookie and stores data in files or Redis. WordPress and most of the legacy web run on exactly this model.
Express with express-session
Node.js apps use the express-session middleware, typically backed by connect-redis, to issue and validate session cookies on every request.
Spring Session
Java web apps externalize the HttpSession into Redis or a database via Spring Session so multiple instances behind a load balancer share state.
Frequently asked questions
- What is the difference between a session and a cookie?
- A cookie is a small piece of data the browser stores and sends back on each request. A session is the server-side data about a user. The cookie usually just carries the session ID, and the server uses that ID to find the real session data. The cookie is the ticket; the session is what the ticket points to.
- What is the difference between a session and a JWT?
- With server-side sessions the server stores the data and the cookie holds only an opaque ID, so the server looks it up each request and can revoke it instantly. With a JWT the data lives inside a signed token in the client, so the server only checks the signature and stores nothing, but you cannot easily revoke a token before it expires.
- How long should a session last?
- It depends on risk. Sensitive apps like banking use short idle timeouts around 15 minutes, while consumer sites may keep you logged in for days or weeks. Sliding expiry is common: the timer resets on each request so active users stay in while inactive sessions expire.
- Why do sessions make horizontal scaling harder?
- Session data is server state. If it lives in one server's memory, a request routed to a different server cannot find it. You either pin users to one server with sticky sessions, which is fragile, or move sessions to a shared store like Redis that every server can read.
- What is session fixation and how do you prevent it?
- Session fixation is when an attacker sets a known session ID in your browser before you log in, then reuses that same ID after you authenticate. The fix is to issue a brand new session ID at login and any privilege change, so the pre-login ID becomes worthless.
Learn Session hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Session as part of a larger topic.
Monotonic Reads
Once you have seen a value, you never see an older one, the minimum useful consistency guarantee
advanced · consistency models
Session Windows
Dynamic windows based on activity gaps, group events by user sessions with configurable timeouts
advanced · stream batch processing
Session Affinity
The broader concept behind sticky sessions, soft preferences vs. Hard pinning
foundation · load balancing proxies
Cookie-Based Sessions
Using HTTP cookies to maintain user state across requests, the traditional session model
intermediate · security architecture
JWT Sessions
Using JWTs as session tokens: the trade-offs, pitfalls, and best practices
intermediate · security architecture
See also
Related glossary terms you might want to look up next.
Stateless
A system where each request contains all the information needed to process it. The server doesn't remember previous requests. Easier to scale horizontally.
Stateful
A system that remembers previous interactions. The server keeps track of client state between requests, making it harder to scale but sometimes necessary.
JWT
JSON Web Token: a compact, self-contained token for transmitting claims between parties. The server can verify it without a database lookup.
Latency
The time delay between sending a request and getting a response. Amazon found every 100ms of extra latency costs 1% in sales.
Throughput
The number of operations a system can handle per unit of time. Think of it as how many cars a highway can move per hour.
Bandwidth
The maximum amount of data that can be transferred over a network in a given time. It's the width of the pipe, not how fast the water flows.