Microservices - Connection Pooling when connecting to a single legacy database

Question

I am working on developing micro services for a monolithic application using spring boot + spring cloud + spring JDBC. Currently, the application is connecting to a single database through tomcat JNDI connection pool.

We have a bottleneck here, not to change the database architecture at this point of time because of various reasons like large number of db objects,tight dependencies with other systems,etc.

So we have isolated the micro services based on application features. My concern is if we develop microservices with each having its own connection pool, then the number of connections to the database can increase exponentially.

Currently, I am thinking of two solutions

1. To calculate the number of connections that is being used currently by each application feature and arriving at max/min connection params per service- which is a very tedious process and we don't have any mechanism to get the connection count per app feature.

2. To develop a data-microservice with a single connection pool which gets the query object from other MS, triggers the query to the database and returns the resultset object to the caller.

Not sure whether the second approach is a best practice in the microservices architechture.

Can you please suggest any other standard approaches that can be helpful in the current situation?

Answer 1

It's all about the tradeoffs.

1. To calculate the number of connections that is being used currently by each application feature and arriving at max/min connection params per service.

Cons: As you said, some profiling and guesswork needed to reach the sweet number of connection per app feature.

Pros: Unlike the second approach, you can avoid performance overhead

2. To develop a data-microservice with a single connection pool which gets the query object from other MS, triggers the query to the database and returns the resultset object to the caller.

Pros : Minimal work upfront

Cons: one more layer, in turn one more failure point. Performance will degrade as you have to deal with serialization -> Http(s) network latency -> deserialization->(jdbc fun stuff which is part of either approach) -> serialization -> Http(s) network latency -> deserialization. (In your case this performance cost may be negligible. But if every millisecond counts in your service, then this is a huge deciding factor)

In my opinion, I wouldn't split the application layer alone until I have analyzed my domains and my datastores.

This is a good read: http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/