Question

At work, we have several applications with databases in a centralized SQL server. Whenever one application needs to work with data from another application, it just queries it or updates it through the database. I believe this is the “Shared Database” pattern as described in the Enterprise Integration Patterns book (Hohpe & Woolf).

These cross database dependencies are causing us many, many headaches. The largest of these right now is that we’re running into performance issues on the SQL server, and can’t scale out because of the cross-database dependencies. I think what we should do is move away from the Shared Database pattern towards a messaging system as described in the EIP book. Each application would be responsible for all of it’s own data, and other apps that want to access that data would get it through services (on a messaging bus?).

• Where do we start refactoring towards the messaging pattern?
• Do we start by refactoring one of the applications to manage its own application database?
• Then what about the other applications are currently integrated with that one through the database?
• Is this the best way to decouple our database dependencies or should we be starting somewhere else?

Answer 1

I’d suggest a 3 phase transition.

1. Add a messaging layer to each of your applications.
2. Change all cross-application data access to use the newly created messaging layer.
3. Scale the (now-independent) databases as needed.

Also, say you have 3 applications; A, B, and C.

You could also view this as 3 separate transitions:

• Application A

  • Add Messaging to A
  • Change Calls to A in B & C

• Application B

  • Add Messaging to B
  • Change Calls to B in A & C

• Application C

  • Add Messaging to C
  • Change Calls to C in A & B

At this point in the process the results are the same as at the end of phase 2, and phase 3 can proceed. The difference is simply whether it is more productive to focus on a type of refactoring or to focus on an application.