The design in this article is barely using AWS at all, basically just using it for server hosting which is causing them to do way more devops than needed. There

The design in this article is barely using AWS at all, basically just using it for server hosting which is causing them to do way more devops than needed. There are parts of this design that could much better leverage AWS and remove a lot of the devops. Sure this means you're tying yourself to AWS but you could re-implement on another system. The whole point of using somthing like aws is to remove all of "extra" work that is not central to your system. Things like redis cluster management, database management, etc. I didn't see what they were doing with mongo and if they needed its access patterns. But I'll assume they do. So I'll keep that part of the design. The rest of the system would like this in an aws design: Ingestion is either timed jobs in lambda or an elastic beanstalk set of processes doing the same. I'm not sure what the ingestion is so I can't say much here. Data gets tossed on a kinesis queue. If possible have the data being ingested tossed on the kinesis queue. Hook lambda workers to the kinesis queue or an elastic beanstalk layer. Kinesis here removes the need to manage a redis cluster. One layer of devops removed. Next you have the workers, the easiest is to toss them in lambda... they'll be invoked to read from the kinesis stream. They'll scale up and down. You don't need to run a supervisor, it's baked into the system. Removing lots of dev ops here, no complicated deploys, no cluster management, etc. If you need 2 different sets of workers you can set a split join set of kinesii... or I believe you can have 2 readers from a kinesis stream they just don't like it if you have lots. [Another variant is just a cluster of Elastic Beanstalk hosts scaling on the side of the kinesis stream] They'll shove data into mongo db... you keep this because you want it. Otherwise use RDS or dynamo if it's suitable. I can't tell. Of course you pay for some of this removal of dev ops. Some of it is free. Lambda limits some of your language choices and is mostly stateless so you may hit some services for things like lookup harder. But the code that is running on lambda can get moved into worker fleets managed by you later if you need more control. The point is here that the interesting parts of your app become the actual code dealing with your specific problem not the devops. Eventually if you have to, you build up more devops and more custom solutions to handle different scale up to meet the scale or price part of the problem. But the solution above will go bigger than most people need and lets you not have to spend hundreds of hours on all that devops at a real cost of engineer time. There are costs everywhere, money, time. Just decide how you want to use them.