A client's Node API needed to scale horizontally behind an Elastic Load Balancer, which meant our old approach of storing sessions in server memory was no longer viable — a user could hit a different instance on every request and find themselves logged out or with a half-completed checkout flow, depending on which box happened to answer. Rather than stand up a Redis cluster just for sessions, we tried DynamoDB, since the client was already on AWS and wanted to minimize the number of moving pieces to operate.
The `connect-dynamodb` middleware for Express made the integration nearly a non-event — it slots in as a drop-in session store the same way any other Express session backend would, with the actual table creation and read/write access handled behind a familiar interface. DynamoDB's pay-per-request pricing meant the session table cost almost nothing at the traffic levels involved, and we did not have to think about provisioning capacity ahead of time the way we would with a self-managed database.
Latency was slightly higher than an in-memory Redis lookup would have been — DynamoDB reads typically landed in the low tens of milliseconds rather than sub-millisecond — but well within acceptable bounds for session reads on this application, since a session lookup happens once per request rather than being on any particularly hot path. We set the table's time-to-live attribute to automatically expire old sessions, which meant we never had to write our own cleanup job for stale session records, something we had previously handled with a cron task on our Redis-backed setups.
One detail worth flagging for anyone trying this: DynamoDB's item size limit means very large session payloads need to be trimmed or restructured, since we ran into a warning on one user whose session had accumulated an unusually large shopping-cart snapshot before we moved cart data into its own table and left the session itself holding just an identifier.
We also had to adjust our mental model around consistency. DynamoDB's default reads are eventually consistent, which is fine for session data where a read immediately after a write on a different request is rare, but we explicitly opted into strongly consistent reads on the one code path — re-authenticating a user mid-request after a password change — where reading a stale session value would have caused a confusing, hard-to-reproduce bug.
For a team that already lives in AWS and wants one less service to run, it is a solid, boring choice. We would still reach for Redis on projects with heavier session traffic or where sub-millisecond latency genuinely matters, but for this client's traffic profile, DynamoDB removed an entire piece of infrastructure we would otherwise have had to provision, monitor, and keep patched ourselves.