I'm developing a platform that allows users to run their own Python trading bots. Each bot operates within its own Docker container, and since I currently have 10 users running 3 strategies each, that adds up to 30 containers running at once. I'm wondering if this approach is appropriate for scalability.
Right now, I'm experiencing some issues: when a user attempts to stop all their strategies, the system lags significantly due to the closing of all those Docker containers. Additionally, I fetch balances and other data every 30 seconds, which makes the web interface feel slow.
As I aim to scale this system to accommodate over 500 users, I'm questioning if I need to rethink my entire architecture. Any insights from those with similar experiences would be greatly appreciated!
1 Answer
It sounds like you're overloading the system with too many containers for user strategies. Instead of giving each user their own container for every strategy, consider consolidating your containers. You could merge processes running similar strategies into a single container and track user actions separately. This could significantly reduce the strain on your system and make it easier to manage. Your current method is simple to implement but not scalable. Spin up new containers only when your current ones start to overload. That's the way to go!
So you're suggesting that when a user starts a second strategy, I would stop the first container, save its state, and then add the new strategy to the existing container? Sounds like a complicated process, but it could definitely reduce the number of containers!