A challenging solution needed

Some years ago I was presented to a project that needed a solution. No news at this point, that is the reality of any IT professional on daily basis.

But then they started talking about the requirements… well, let me show them:

1. They had a web-based system running in that classical way: a new company pay for using, you install it in some server on their network and everybody inside the company access the system using a web browser (the damn IE);
2. The system was built in Java 4 and there’s was no chance to upgrade to Java 7 (the latest version that time);
3. The system was deployed at Tomcat 4 and there’s was no chance to upgrade;
4. They didn’t use connection pooling for database connection. Worst: each user opens a connection with database when login into the system and that connection was hold into the session. Here they would accept a refactoring, but the whole scenario won’t;
5. They needed the system to be available online in a SAAS way:
   • Each new user would create its new account online and pay the signature with credit card;
   • The system couldn’t be refactored for avoiding users to see each others data. Talking in another words, a system built for running in one single company at time needed to be available in one single platform, for as many companies as possible at time, protecting the users data as it was supposed to do, and COULD NOT be refactored for it.
6. The budget for the project was almost zero (no news either);
7. The deadline was almost instantaneous.

My first reaction was laughing, but then I realized they was talking serious… “Ok, let me think for a day…”

Well in fact it didn’t took me a long time to design the right solution. I have to be honest, it wasn’t the prettiest and neither the coolest solution I had ever did, but was fine for what they needed to do, in the way they wanted to do and spending the much they wanted to spend.

The big challenge: segregate the users data in the same environment with a system that just was not built for it and couldn’t be deeply refactored

(Big subtitle for a big problem)

To solve this challenge I did one thing that solved many challenges in this project: a facade application. The user could not see it, but he/she was in fact using two systems: one, the facade, was responsible for managing the users, grants, profiles, signature status and, more important, the authentication and database redirection; the other one, the old system.

Instead of keeping the database access tied to application configuration files, I moved it to a session variable. So when the facade application did the authentication and found the right database for that user/company, it passed those data to the system (cross context applications) and then it could open its connection and do whatever it needed to do as nothing different was happening.

When a new user registered at the company site, this same facade application started creating that user: registering account, authorizing the payment and… creating the database. Each new user won its own database in the system database server.

So there was a “model” database and each new database was created based on it.

To support it we created five database instances in the database server and created a “manual” round-robin that created each new user in the instance that was less loaded. The facade application was also able to do it in many servers if they were mapped.

So we did a “database load balancing” manually! 😉

 

Now… everything is just funny

The really big problem was to separate the users data. Once it was done in a skillful way, the rest of the project was the usual stuff: buttons here and there, popups, etc, etc, etc.

The system was deployed in a cloud solution that made the things moving even more faster and cheaper. We probably released the first version in less than a month after the first meeting…

 

So why the hell I am here sharing this little case. I think we could take some lessons here:

1. Just because your client is very very very very very restrictive it doesn’t means you can’t find a solution for his/hers problems (even if it sucks…);
2. The right solution maybe can be the ugly one;
3. Being creative could save you time, money and headache.

 

Any comments? Just leave it bellow!