0

Say I have an application/service A. This application will continuously take in some input X, process it and store it in some database T. This process is quite resource intensive.

Now you also wish, as a user, to have access to the data in T so you need endpoints for retrieving and updating this data from the database.

My question is should these endpoints get exposed by A. Since its constantly under heavy load would it be beneficial to create a new application B, give it access to database T and let it handle all requests for this data?

Assuming these requests are quite frequent, it would spare an additional load on A.

Would this be considered good/common practice?

1

Its a question of ease of programming and deployment.

You have services A and B, when you run your application/solution as a whole A is under heavy load, B is under light load.

In order to prevent A being a bottle neck you want to add more CPU resource to A, but not to B as it would just go unused.

If you are using powerful multicore boxes you might as well put both A and B on all the boxes, and if you are good at multiprocessor programming, even have them in the same application. The OS will divide up the available processing power as per the needs of each application, some B's will never get any load but it wont matter as the overhead of running a idle B is insignificant.

Your deployment is pretty simple because you just put all your micro-services on every box and just scale the number of boxes. If load unexpectedly increases on B you can maybe use up some slack in your A processing without having to worry.

If however you are using tiny containers that can barely handle a single A, you might want to consider the overhead of running B when its not going to get any traffic.

Or maybe each instance only has a single processor which will have to switch between working on A and B causing delays.

In this case you might find it better to separate A and B into different programs. then you have have boxes dedicated to A or B and scale them up independently.

Your deployment is more complex, but your code is simplified and its arguably more efficient resource usage. If load on B increases or A decreases you have to worry about adjusting the scaling levels, rather than just having one big pool.

I've seen both done and I don't think there is a huge difference either way tbh. I don't think i would go as far as combining the two services in a single application though. Unless you were querying the live job being processed or something.

A central database T adds an extra wrinkle, as you obviously want to avoid it becoming a bottleneck in its self. But I think this is a common solution.

3
  • Thanks for the input. In this case each application would be run as docker containers. So they would be deployed and scaled independently. I take it from your answer you're leaning more towards having a separate application B, for data access as opposed to one multihreaded application. One concern I have with two applications which share a database, or database table, T is that it violates a basic principle of microservices architecture, where A and B are microservices.
    – kasmoada
    Sep 4 at 17:08
  • yes, I would add a third service C which would be an API to wrap the DB, or maybe B is that API?
    – Ewan
    Sep 6 at 14:28
  • Yes, application B would expose that API.
    – kasmoada
    Sep 6 at 15:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.