Sticky sessions and CDNs for static content
40 min · Intermediate
Two tools decide where a ShopLite request goes before it reaches any Java code: the load balancer, which may or may not pin a user to one server, and the CDN, which answers requests for images, scripts and styles from a server near the user.
Topics in this lesson
- Sticky sessions and their problems
- Stateless servers are easier
- CDN basics: edge, origin and cache hits
- What to put on a CDN: headers and versioned files
- ShopLite's request path
Key points
- Sticky sessions pin a user to one server (cookie or IP hash); they cause uneven load, lost sessions on crashes and slow scale-in.
- Stateless servers with Redis sessions or JWTs need no stickiness, so any algorithm works and crashes lose nothing.
- A CDN serves static files from nearby edge servers and fetches from the origin only on a miss.
- Version static files by content hash and cache them for a year; keep HTML
no-cacheand personal API data off the CDN.
Interview questions this lesson answers
- What are sticky sessions and why are they a problem at scale?
- How do you avoid sticky sessions?
- What is a CDN and how does it help?
- What would you put on a CDN for ShopLite?
- How do you release a new version of app.js without users getting the old one from caches?
- Walk me through ShopLite's request path for a product page.
Sign in to continue this lesson
Create an account to read every lesson, practise with the exercises and keep track of your progress.