We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningFoundation · Core Fundamentals
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).
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Session across a run of lessons, not one page. These 4 alone are about 85 minutes of step-by-step reading, every one with a quiz.
How servers remember who you are between requests in a stateless protocol.
Once you have seen a value, you never see an older one, the minimum useful consistency guarantee.
Dynamic windows based on activity gaps, group events by user sessions with configurable timeouts.
Where the session actually lives, and why that one choice decides routing, deploys, scaling and failover.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Session Managementpay once,
yours for life
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Monotonic Reads
Once you have seen a value, you never see an older one, the minimum useful consistency guarantee
Session Windows
Dynamic windows based on activity gaps, group events by user sessions with configurable timeouts
Session Affinity
Where the session actually lives, and why that one choice decides routing, deploys, scaling and failover
Cookie-Based Sessions
Using HTTP cookies to maintain user state across requests, the traditional session model
JWT Sessions
Using JWTs as session tokens: the trade-offs, pitfalls, and best practices
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.
This page explains the idea. The "Session Management" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Session Management lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Session in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
