Stateful Services

Stateful services maintain information about client sessions across requests.

Types of State

1. Session State
   - User login information
   - Shopping cart contents
   - User preferences

2. Application State
   - In-memory cache
   - Connection pools
   - Rate limiting counters

3. Distributed State
   - Leader election
   - Distributed locks
   - Coordination data

State Management Patterns

1. In-Process State
   State stored in server memory
   Fast but not shareable
   
   Client → Server A (state in memory)
   Client → Server A (same server required)

2. External State Store
   State stored in Redis/Memcached
   Shareable across servers
   
   Client → Any Server → Redis → State

3. Database State
   State stored in database
   Persistent but slower
   
   Client → Any Server → Database → State

State Consistency

Challenge: Keeping state consistent across servers

Solution 1: Single Source of Truth
- All servers read/write to same store
- Redis, database

Solution 2: State Replication
- State replicated across servers
- Consensus algorithms (Raft)

Solution 3: Eventual Consistency
- State may be temporarily inconsistent
- Conflict resolution strategies

Session affinity (sticky sessions) routes the same client to the same server.

How Session Affinity Works

Client A → Load Balancer → Server 1 (stores session)
Client A → Load Balancer → Server 1 (sticky)
Client B → Load Balancer → Server 2 (stores session)
Client B → Load Balancer → Server 2 (sticky)

Implementation Methods

1. IP-based
   Hash(Client IP) → Server
   
   Problem: NAT, load balancers hide real IP

2. Cookie-based
   Server sets cookie with server ID
   Client sends cookie on subsequent requests
   
   Example: JSESSIONID=server1

3. URL-based
   Session ID in URL path
   Example: /app/SESSION123/page

Nginx Configuration

# IP Hash
upstream backend {
    ip_hash;
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

# Cookie-based
upstream backend {
    hash $cookie_jsessionid consistent;
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

Session Affinity Problems

1. Server Failure
   - Session data lost
   - User must re-login

2. Uneven Load
   - Long sessions → more traffic to one server
   - Poor load distribution

3. Scaling Difficulty
   - Can't freely add/remove servers
   - Session migration needed

4. Deployment Complexity
   - Must maintain sessions during deployment
   - Can't use blue-green easily

When to Use Session Affinity

Scenario	Use?	Alternative
Simple apps	Maybe	External store
Legacy apps	Yes (temporarily)	Migrate to stateless
Performance critical	Yes	Redis with connection pooling
High availability	No	External state store

External state stores decouple state from application servers.

Redis as State Store

Architecture:
Client → Any Server → Redis → Session Data

Benefits:
- Any server can access any session
- Fast (in-memory)
- Persistent options available
- High availability with replication

Redis Session Configuration

const session = require('express-session');
const RedisStore = require('connect-redis').default;
const redis = require('redis');

const client = redis.createClient({
  host: 'redis-cluster.example.com',
  port: 6379
});

app.use(session({
  store: new RedisStore({ 
    client,
    prefix: 'sess:'
  }),
  secret: 'your-secret',
  resave: false,
  saveUninitialized: false,
  cookie: { 
    secure: true,
    httpOnly: true,
    maxAge: 86400000  // 24 hours
  }
}));

Memcached vs Redis

Aspect	Memcached	Redis
Data types	Strings only	Multiple types
Persistence	No	Yes
Replication	No	Yes
Clustering	Yes	Yes
Use case	Simple caching	Complex state

Distributed State with Consensus

For critical state (leader election, locks):

ZooKeeper / etcd:
- Raft/Paxos consensus
- Strong consistency
- Leader election
- Distributed locks

Use Cases:
- Database leader election
- Distributed lock service
- Configuration management
- Service discovery

State Store Best Practices

1. Choose appropriate store: Redis for sessions, Memcached for cache
2. Set TTL: All state should expire
3. Monitor memory: State stores can run out of memory
4. Plan for failover: Replication and backup
5. Encrypt sensitive data: Don't store plaintext secrets