Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

Horizontal Scale and Shared State

Last updated: 5 Oct 20266 min read
tutorial
IntermediateBy AITrove Editorial

Adding more service instances increases capacity only when they agree on durable state and authorization decisions. A process-local session map or idempotency cache works in one worker and fails when the next request reaches another. Store shared sessions, records, counters, and idempotency results in systems designed for that scope. A load balancer distributes requests, but sticky routing is not a substitute for clear state ownership or failure recovery. Plan for workers to restart at any time. The same case write must remain correct no matter which healthy instance receives it.

Working case

A reviewer signs in through worker A, then submits case 47 through worker B. If session state lives only in A's memory, B reports an unexpected sign-out. A shared session store lets B validate the same opaque cookie. If a retry reaches worker C, an idempotency record in durable shared storage returns the first result. The application can scale reads and writes independently only after its storage and transaction contracts support that traffic. The injected service interfaces below keep request handling independent of the process that receives it.

Implementation

javascript
async function handleCaseRead(request, sessionStore, caseStore) {
  const session = await sessionStore.get(request.sessionId);
  if (!session) return { status: 401 };
  const allowed = await caseStore.canRead(session.reviewerId, request.caseId);
  if (!allowed) return { status: 403 };
  const record = await caseStore.get(request.caseId);
  return record ? { status: 200, record } : { status: 404 };
}

Cost and boundaries

Each shared-state lookup adds network latency and load to the store. More app workers can make a database the bottleneck; pool connections and measure queueing, not only CPU. Replication lag affects reads that expect a just-committed write, so decide when a primary read is required. Stateless application processes simplify replacement, but the system still has state in databases, caches, queues, and object storage. Capacity testing should include failover and mixed worker versions during rollout.

Common Mistakes

  • Do not store critical sessions only in one worker's memory.
  • Do not assume sticky routing is a durability strategy.
  • Do not add app instances without measuring shared-store capacity.

Connected lessons

Deployment and Scale; Environment Configuration and Secret Boundaries; Continuous Integration and Release Gates; Backup and Restore Drills; Release checks: prove the critical route and prepare a rollback; Observability: connect user failure to a safe request trace; DevOps: delivery, infrastructure, and reliable operations.

Failure trace

A session works on worker A and disappears on worker B. The team adds sticky routing, then a restart still loses every session because the state lives in process memory. Put cross-request state behind a shared store or a validated signed session design, and make handlers safe to run on any instance. Local caches can remain local if missing one changes speed rather than correctness.

Verification

  • Alternate requests between two instances and confirm the same authorized session is recognized.
  • Restart one instance during a write and check that the committed result remains available.
  • Expire a shared session and verify every instance rejects it without waiting for a local cache.

Decision note

Adding servers only helps if the bottleneck can be distributed. Measure database saturation, connection counts, and queue pressure before assuming more application processes increase throughput.

Apply and check

Build Project: release and recovery drill for a content service; then check the boundary with Web Development: offline and delivery contracts quiz.

web-tech
web-development
Storage details