Passport.js session serialization vs passport-jwt with session:false when the load balancer already pins sticky sessions

I'm designing authentication for an Express app that will run behind a load balancer configured with sticky sessions (cookie-based affinity). Passport supports both approaches I'm weighing: the classic serializeUser/deserializeUser hooks backed by express-session, and the passport-jwt strategy with session: false so no server-side state is kept at all.

My concrete constraint is revocation. With sessions, logging out or disabling an account is a store delete. With stateless JWTs, the token stays valid until exp, so I'd need short-lived access tokens plus refresh rotation, or a denylist keyed by jti — which reintroduces the shared state I was trying to avoid. Sticky sessions make even the default session setup work today, but I don't want to depend on affinity if the fleet later scales or rebalances.

Assume Express 4, current Passport 0.6/0.7 line, and HTTPS everywhere.

Given that revocation matters and sticky sessions are guaranteed only for now, which trade-off is more defensible: a Redis-backed session store from day one, or JWT with short exp and refresh rotation? Does skipping deserializeUser per request with session: false meaningfully reduce latency if user lookup hits a database? Are there pitfalls running both strategies side by side (sessions for browser routes, JWT for API routes) in one Passport setup?