There are two modules A and B using the same DB. A imports B as a JAR. I read that messaging patterns can replace the tightly coupled solution of using a shared DB but I am not sure which message pattern I can use.

A high level solution that indicates how we can stop using the shared DB, would be great.

Adding more details as requested:

Imagine A like a huge app (let's say Flickr) and B a plugin for A that periodically runs as a daemon and among other things calculates several user ranks (e.g. user with the most comments, most highly rated pictures, etc.). In order to do that it uses A's DB and does most calculations using stored procedures which again live in A's DB.

The rest of the code is decoupled but I was wondering how I could loose the database dependency, so that any changes in the database schema or implementation won't break B.

  • 3
    We'd have to know a little bit about what A and B actually do to offer any advice on what "messaging pattern" might be appropriate. Could you add some more details?
    – Ixrec
    Apr 15, 2016 at 15:42
  • If B relies on a stored procedure to get its data, how would a change in db schema affect your application? It's the stored proc that would have to change. Even if you had an API or Module A created some sort of data file, a change in the schema will possibly necessitate a change in the creation of that file. You haven't really saved yourself from having to address changes.
    – JeffO
    Apr 15, 2016 at 20:45
  • @JeffO Yes, you're right as you put it. I am free to refactor pretty much anything though, including the stored procedures. I am just looking for any solution no matter how far away from the current that could work.
    – Michael
    Apr 17, 2016 at 2:42

1 Answer 1


Lets to do an exercice of creativity

A's API Rest as webservice: In order to feed B and unbind B from A's data model , we need an interface that will act like a contract. This contract is going to be our webservice data model.

B as standalone app: Lets wrap B into a standalone app that could be executed anywhere. Desktop or web doesn't matter. Lets say desktop in order to launch it via O.S daemon.

Now B is a client of A that ask for its Info with a pacted data model that may or may not be as A data model is.

Point is that webservice's data model can be different from the original one.


  • B need its own data model. Absolutly
  • A's webservice data model may change over time. But we invented API rest versions for this cases
  • Access to A's webservice should be securized somehow (little more extra work :-) )
  • If you expect many request from B to A, a system of cache is going to be must (more work, don't hate me)

However we need to know your platform configuration and its boundaries. But this would be a possible aproach.

Hope it helps.

  • Thanks it does help. Just out of curiosity, do you have an idea of how messaging could possibly help here?
    – Michael
    Apr 17, 2016 at 2:44
  • Yes. Message pattern will do the same but instead of B asking A every X time, A will put a message into a queue (or any other channel), B (who is subscribed to this queue/topic, will consume it). Both aproach, mine and yours can be considered messaging pattern. Checkout Wikipedia definition
    – Laiv
    Apr 17, 2016 at 9:21

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