How do I scale a Java app with a REST API and a Database?

Question

I have a typical stateless Java application which provides a REST API and performs updates (CRUD) in a Postgresql Database.

However the number of clients is growing and I feel the need to

• Increase redundancy, so that if one fails another takes place
• For this I will probably need a load balancer?
• Increase response speed by not flooding the network and the CPU of just one server (however how will the load balancer not get flooded?)
• Maybe I will need to distribute the Database?
• I want to be able to update my app seamlessly (I have seen a thingy called kubernetes doing this): Kill each redundant node one by one and immediately replace it with an updated version
• My app also stores some image files, which grow fast in disk size, I need to be able to distribute them
• All of this must be backup-able

This is the diagram of what I have now (both Java app and DB are on the same server):

What is the best/correct way of scaling this?

Thanks!

Answer 1

Web Servers:

Run your app on multiple servers, behind a load balancer. Use AWS Elastic Beanstalk or roll your own solution with EC2 + Autoscaling Groups + ELB.

You mentioned a concern about "flooding" of the load balancer, but if you use Amazon's Elastic Load Balancer service it will scale automatically to handle whatever traffic you get so that you don't need to worry about this concern.

Database Servers:

Move your database to RDS and enable multi-az fail-over. This will create a hot-standby server that your database will automatically fail-over to if there are issues with your primary server. Optionally add read replicas to scale-out your database capacity.

Start caching your database queries in Redis if you aren't already. There are plugins out there to do this with Hibernate fairly easily. This will take a huge load off your database servers if your app performs the same queries regularly. Use AWS ElastiCache or RedisLabs for your Redis server(s).

Images:

Stop storing your image files on your web servers! That creates lots of scalability issues. Move those to S3 and serve them directly from S3. S3 gives you unlimited storage space, automated backups, and the ability to serve the images directly from S3 which reduces the load on your web servers.

Deployments:

There are so many solutions here that it just becomes a question about which method someone prefers. If you use Elastic Beanstalk then it provides a solution for deployments. If you don't use EB, then there are hundreds of solutions to pick from. I'd recommend designing your environment first, then choosing an automated deployment solution that will work with the environment you have designed.

Backups:

If you do this right you shouldn't have much on your web servers to backup. With Elastic Beanstalk all you will need in order to rebuild your web servers is the code and configuration files you have checked into Git. If you end up having to backup EC2 servers you will want to look into EBS snapshots.

For database backups, RDS will perform a daily backup automatically. If you want backups outside RDS you can schedule those yourself using pg_dump with a cron job.

For images, you can enable S3 versioning and multi-region replication.

CDN:

You didn't mention this, but you should look into a CDN. This will allow your application to be served faster while reducing the load on your servers. AWS provides the CloudFront CDN, and I would also recommend looking at CloudFlare.