📜 Description
Summary
The backend currently uses the default express-session MemoryStore in production.
MemoryStore is explicitly documented as:
- non-production-ready,
- memory-leaking under real traffic,
- non-persistent,
- and incompatible with horizontal scaling.
As implemented, all authenticated sessions:
- exist only in process memory,
- are lost on restart,
- and accumulate without durable persistence.
Affected Files
backend/server.js
backend/package.json
docker-compose.yml
Root Cause
express-session is initialized without a configured session store:
app.use(session({
secret: process.env.SESSION_SECRET,
resave: false,
saveUninitialized: false,
}));Without a store: option, Express falls back to the built-in MemoryStore.
The official express-session documentation explicitly warns:
MemoryStore is not designed for production use. It leaks memory, does not scale past a single process, and is meant only for debugging/development.
Failure Scenarios
1. Session Loss on Restart
Any:
- deploy,
- container restart,
- crash,
- OOM kill,
- or process recycle
immediately destroys every authenticated session.
All users are silently logged out.
2. Memory Growth Under Real Traffic
Sessions accumulate in the Node.js heap with:
- no persistence,
- no centralized storage,
- and unreliable cleanup behavior.
Under sustained traffic:
- heap usage grows continuously,
- garbage collection pressure increases,
- and the process eventually becomes unstable.
3. Horizontal Scaling Failure
With multiple backend replicas:
User logs in → instance A
Next request → routed to instance B
Session missing → user appears logged out
The application becomes incompatible with:
- load balancing,
- autoscaling,
- or multi-instance deployments.
Reliability Impact
This creates:
- production instability,
- forced user logout loops,
- deployment fragility,
- memory exhaustion risk,
- and broken multi-instance behavior.
The application cannot scale safely in its current state.
Proposed Fix
Replace MemoryStore with a production-grade session backend.
Recommended options:
Option 1 — Mongo-backed Sessions
Use:
since MongoDB already exists in the stack.
Option 2 — Redis-backed Sessions
Use:
for distributed deployments.
Suggested implementation:
store: MongoStore.create({
mongoUrl: process.env.MONGO_URI,
ttl: 14 * 24 * 60 * 60,
})Additional recommendations:
- enable secure cookie flags,
- add session TTL cleanup,
- document required environment variables.
Acceptance Criteria
- MemoryStore removed from production usage
- sessions persist across backend restarts
- sessions support multi-instance deployments
- session TTL cleanup configured
- deployment documentation updated
- regression testing/manual verification added
Why This Matters
This is a production-blocking infrastructure flaw.
Without a persistent session store:
- deployments are unreliable,
- scaling is impossible,
- and authenticated user experience becomes unstable under normal operational conditions.
What browsers are you seeing the problem on?
No response
📃 Relevant Screenshots (Links)
No response
📜 Description
Summary
The backend currently uses the default
express-sessionMemoryStore in production.MemoryStore is explicitly documented as:
As implemented, all authenticated sessions:
Affected Files
Root Cause
express-sessionis initialized without a configured session store:Without a
store:option, Express falls back to the built-in MemoryStore.The official express-session documentation explicitly warns:
Failure Scenarios
1. Session Loss on Restart
Any:
immediately destroys every authenticated session.
All users are silently logged out.
2. Memory Growth Under Real Traffic
Sessions accumulate in the Node.js heap with:
Under sustained traffic:
3. Horizontal Scaling Failure
With multiple backend replicas:
The application becomes incompatible with:
Reliability Impact
This creates:
The application cannot scale safely in its current state.
Proposed Fix
Replace MemoryStore with a production-grade session backend.
Recommended options:
Option 1 — Mongo-backed Sessions
Use:
since MongoDB already exists in the stack.
Option 2 — Redis-backed Sessions
Use:
for distributed deployments.
Suggested implementation:
Additional recommendations:
Acceptance Criteria
Why This Matters
This is a production-blocking infrastructure flaw.
Without a persistent session store:
What browsers are you seeing the problem on?
No response
📃 Relevant Screenshots (Links)
No response