I have two web applications, say Application_1 and Application_2.

Application_2 has a database table named table_2, which changes infrequently, and needs to be accessed by Application_1.

Does it make sense to create a table_2 table in Application_1 and update it with an ETL task?

A straightforward solution would be expose the data through a REST API in Application_2, but this will break the decoupling between both applications and introduce a new point of failure in Application_1.

4 Answers 4


Since you tagged the question with SOA, I suspect that you're thinking the right answer might be using a service interface. Such a service interface should not expose the data, but the functionality you want to provide as a contract to be exposed by one application and consumed by the other application.

As the question is being asked in the abstract, this contract could range anywhere from providing answer to a very specific lookup to an event stream notifying the consumer of changes.

Either application (i.e. on either or both sides of the service interface) can make use of caching (copy of table) if they need to, but caching is an optimization that should not be prematurely applied.

Either way, these applications are coupled. The ETL job you suggest will also couple the applications and probably result in a more poorly understood contract between the them than a well-designed service interface.

  • I tagged the question with SOA because I am familiarised with the concepts of decoupled services divided by responsibility but the truth is I have no experience in the subject. So basically what you are suggesting is to create an isolated service which provides a read/write interface for Application_1 and Application_2. In that case, where would table_2 be stored? Because of the nature of Application_2 I need to keep table_2 in Application_2 because it is referenced by other tables.
    – carpamon
    Jul 30, 2015 at 18:00
  • I was suggesting that the service interface be implemented by an endpoint provided by Application 2, for the benefit of Application 1 who needs access to table 2. Btw, coupling is a matter of degree. The better defined the service interface, the looser the coupling will be because you won't be overexposing implementation details.
    – Erik Eidt
    Jul 30, 2015 at 19:28

The best way is to make the REST api but copy data over in a scheduled job. Sharing databases should always be avoided between solutions. Remember we don't share toothbrushes and connectionstrings.

By exposing the inner workings of the db you lock the cadance of both apps to each other and neither of them can have their inner workings changed to a more appropriate technology in the future. The rest api sidesteps this problem.


One way of doing this would be to creation an Application_3_API_service which would expose an API to both Application_1 and Application_2.

All services that currently do read/write operations in Application_1 and Application_2 would now hit various endpoints exposed on Application_3_API_service.

The only application with a database connection would be Application_3_API_service.

+---------------+     +---------------+
| Application_1 |     | Application_2 |
+---------+-----+     +--------+------+
          |                    |
|      Application_3_API_service      |
  • 2
    You mean moving table_2 to a private service Application_3_API_service and let Application_1 and Application_2 access that service? In that case, how do you handle database joins when the data is no longer in a database and is accessed through an API?
    – carpamon
    Jul 30, 2015 at 17:57
  • You define such queries within Application_3_API_service and serve it from an API endpoint that lets you define params... for example, lets say that your application has two tables, Accounts and Cities. You want all accounts from a certain city. You can do: GET: application3.com/api/cities/Toronto/accounts/ This will get all accounts from a given city as defined by its String name.... in this case, Toronto This pattern will let you clearly define the inputs and outputs of your applications. It will also let you handle race conditions, and also let you cache results, all within Application 3. Jul 30, 2015 at 18:31
  • And yes, table_2 will be accessed only by Application_3_API_service. Jul 30, 2015 at 18:36

The question posed indicates that your service boundaries are wrong. The service should be self-contained, it should not expose any data or let other services operate upon its data. A service should expose behaviour instead -- just like any object.

The real question is how to identify service boundaries so that the resulting services will be loosely coupled, highly cohesive and autonomous.

So here is my take on it: I found it profitable to decompose problem space first using business-capability mapping technique, and then map my technical services with 1:1 relation. So my services are intrinsically autonomous and cohesive, with strictly defined single source of truth.

Be wary of sharing your data via events though -- if you need it, most probably than not your boundaries are wrong. If you think you need it for your web-(or any other) interface, Backends for Frontends is the way to go. Events are for triggering sagas, not for data sharing.

Probably this example would be of some interest for you.

  • You are currently writing a lot of answers – great! However, all your answers include at least two links to your blog. That looks very, very spammy. Please try first to answer the question. If you've written a relevant post, then go ahead and link to it, great. But do not set out to contrive opportunities where you can promote some website! Maybe go slow on the self-promotion, before you might get banned.
    – amon
    Sep 26, 2017 at 16:38
  • Spam means irrelevant or inappropriate content. I hope that my content is relevant and appropriate. Accepted your warning though, thanks. Sep 26, 2017 at 16:52

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.