Managing State
Stateful server: server A holds data that other servers cannot acces
Stateless server: servers share the same storage system
Managing HTTP Session
- HTTP Session: servers could use to recognize multiple requests from the same user as parts of a more complex and longer lasting sequence
- Session are implemented using cookies
Problem with using cookies:
- Good for minimal identifier data. If data is big, the requests can get slow.
- Alternative 1: use additional session storage system, use a session identifier to load session data
- The session storage: need to have low put-by-key and get-by-key latency
- Alternative 2: use load balance, but avoid sticky session: not stateless
Managing files
- Always try to use a CDN provider to deliver public files to end users (with long expiration policy)
- If file is private: all file download requests will have to go to front-end web application servers rather than being served by CDN
- S3:
- public buckets: serve public files, high availability and scalability
- private buckets: serve a private file: need to download it to front-end web application server
Managing Other State
- Local server cache
- Cache inconsistency example: real-time bidding system: should use a shared object cache
- Application in-memory state
- Resource locks
- Locks are used to prevent race conditions and to synchronize access to shared resources
A common way of scaling out: isolate a piece of functionality that requires a globally available state, remove it from the application, and create a new independent service encapsulating this functionality
- downside: increased latency
Keeping servers stateless will let you scale them easily by adding more clones.