Application state is the data representing a service’s current condition. In Kubernetes, its location determines whether replicas can serve requests consistently and scale with demand. section 2.4 section 2.4.3
Design state handling around the service’s scaling and failure behavior:
- Store state outside pod memory, using components such as Redis or PostgreSQL, so multiple replicas can access shared data. section 2.4.3
- Treat in-memory state as a scaling constraint: load balancing requests across replicas can produce different results when each pod has separate data. section 2.4.3
- Review database connection-pool settings as replicas increase, because every replica can create connections against the database. section 2.4.3
- Handle HTTP sessions deliberately when subsequent requests must reach the same replica, including the need for session replication or sticky sessions. section 2.4.3
Scaling the Conference Agenda service
Run the Agenda service with two replicas. Kubernetes load-balances Frontend requests between them, while Redis keeps the agenda state outside pod memory. If the service instead stores agenda items in memory, each replica can expose different data and scaling becomes unreliable. section 2.4.3
