I am working on scaling a Baileys Node.js server to handle 1K–5K concurrent sessions #1824
Replies: 4 comments 4 replies
|
I am also facing this issue |
|
UP |
|
about redis: for this volume of simultaneous sessions, I do not recommend using a single redis, redis is single thread and can be the bottleneck of the system if all sessions request data at the same time. The best idea is to use independent servers and spread sessions between them so that a session isn't started on two servers at the same time. Depending on your needs (groups or private) it will influence how many sessions you can run in a single nodejs process without generating slowness and event-loop overload Regarding session distribution design, there is no ready-made formula, so you need to create an orchestrator that will monitor all servers and the sessions on them. If one ends, it restarts it on the same server or another. I currently use Docker instances, but I create new instances manually (but it's not difficult to automate this). Regarding session drops, I recommend implementing some logic to restart sessions every few hours. |
|
@erickythierry Do you automatically start a session when the container starts, saving its state in a database, and handle “not connected” states as well? |
|
Yes, I store all session keys in a Postgres DB. When the server starts, it pulls all sessions with its ID from the DB. If a session is disconnected from WPP, the server receives a disconnection error and deletes all session keys from the DB. |
|
@erickythierry can you please explain the full system how you are running inside the containers ? so presently i am following https://waha.devlike.pro/blog/waha-scaling-how-to-handle-500-sessions/ this thing but with some custom modifications |
|
how do you process this amount of requests without being blocked? I built a bot wa groups and was blocked every end of the day. would love to learn more how can I make it work. |
|
I think I manage the resources on my system pretty good. Please visit arrocy.com for 'user' privilege access. I can setup a new demo site for you and test with 'admin' privilege. |
Uh oh!
There was an error while loading. Please reload this page.
Current Setup
Infrastructure:
Tried ECS (Fargate) with 4 tasks behind ALB with sticky sessions enabled.
Using DynamoDB for storing long-term credentials.
Using Elasticache for on-demand socket rehydration (to avoid full login every time).
Each task: 2 vCPU, 4GB RAM.
Behavior:
latency becomes very high.
After ~48 hours, reconnections stop working. ECS tasks get stuck and cannot reconnect sessions automatically.
**Issue with ECS
**
Horizontal scaling with ECS is not working as expected because:
Baileys requires in-memory session handling.
When the session reconnects, it expects the same container unless the rehydration is very fast.
Even with Redis-based rehydration, reconnect latency is too high, causing session drops.
Attempted Alternative
I’m considering switching to a single EC2 instance (2 vCPU, 16 GB RAM) with:
Redis (in-memory) for active sessions.
DynamoDB for credential persistence.
This setup works for ~200 sessions.
But I need to auto-scale this to 1K–5K sessions reliably without losing connectivity.
My Questions
Should I move fully to EC2 vertical scaling with larger memory instances?
Or is there a way to make ECS horizontal scaling work with Baileys?
Is Redis in-memory + DynamoDB for credentials a good approach?
Or should I use a different approach (e.g., sharding sessions across multiple Redis instances)?
How do I design this system so that new sessions automatically get distributed to new nodes?
Is there a working architecture reference for handling thousands of persistent Baileys sessions? so i am pasting like this
All reactions