CODEWITHSUNDEEP
databaseconcurrencyserverload-balancing
MobileDev
MobileDev

Reputation: 176

Load balancer and multiple instance of database design

The current single application server can handle about 5000 concurrent requests. However, the user base will be over millions and I may need to have two application servers to handle requests.

So the design is to have a load balancer to hope it will handle over 10000 concurrent requests. However, the data of each users are being stored in one single database. So the design is to have two or more servers, shall I do the followings?

  1. Having two instances of databases
  2. Real-time sync between two database

Is this correct?

However, if so, will the sync process lower down the performance of the servers as Database replication seems costly.

Thank you.

Upvotes: 1

Views: 3228

Answers (2)

Kemal Atik
Kemal Atik

Reputation: 337

Best option could be the synchronizing the standby node with data from active node as cost effective solution since it can be achievable using open source relational database(e.g. Maria DB).

  • Do not store computable results and statistics that can be easily doable at run time which may help reduce to data size.

  • If history data is not needed urgent for inquiries , it can be written to text file in easily importable format to database(e.g. .csv).

  • Data objects that are very oftenly updated can be kept in in-memory database as key value pair, use scheduled task to perform batch update/insert to relation database to achieve persistence

  • Implement retry logic for database batch update tasks to handle db downtimes or network errors

  • Consider writing data to relational database as serialized objects

  • Cache configuration data to memory from database either periodically or via API to refresh the changing part.

Upvotes: 0

Josh McMillan
Josh McMillan

Reputation: 734

You probably want to think of your service in "tiers". In this instance, you've got two tiers; the application tier and the database tier.

Typically, your application tier is going to be considerably easier to scale horizontally (i.e. by adding more application servers behind a load balancer) than your database tier.

With that in mind, the best approach is probably to overprovision your database (i.e. put it on its own, meaty server) and have your application servers all connect to that same database. Depending on the database software you're using, you could also look at using read replicas (AWS docs) to reduce the strain on your database.

You can also look at caching via Memcached / Redis to reduce the amount of load you're placing on the database.

So – tl;dr – put your DB on its own, big, server, and spread your application code across many small servers, all connecting to that same DB server.

Upvotes: 3

Related Questions