arrow-left arrow-right brightness-2 chevron-left chevron-right circle-half-full dots-horizontal facebook-box facebook loader magnify menu-down RSS star Twitter twitter GitHub white-balance-sunny window-close
Integration: Shared Database
2 min read

Integration: Shared Database

This is an old post and doesn't necessarily reflect my current thinking on a topic, and some links or images may not work. The text is preserved here for posterity.

In my last post, I introduced a scenario where we need to allow two applications to make use of the same customer information:

How do we make these applications talk?

The Web Store already has a SQL Server database. Since we're still designing the Marketing application, we could just make it use the same database. The result would look like this:

We make both applications use the same SQL Server database

This is probably the simplest solution that could possibly work, but it has a few downsides:

  1. Since changes to the schema could affect the other team, changes need to be co-ordinated.
  2. Storage and indexing need to be optimized for the access patterns of both applications, which might be hard to accommodate.

In essence, the key problem is coupling. We create a ripple effect any time we try to change a shared database.

Unless the applications are talking through a façade, such as a stored procedure layer, it's difficult for one application to isolate itself from another.

As the enterprise grows, the effects of this become much worse. If more applications are built on top of this database, adding a column to a table could involve meetings between four or five teams, all with different priorities.

Mommy, where do DBA's come from?

Over time, the database morphs from being "just a place where the application stores its data", to the most critical piece of infrastructure in the organization. To deal with this, organizations often hire dedicated Database Administrators. Their job isn't just to keep the server running, but to act as strict guardians of any changes to the schema.

With DBA's come a strictly defined change control process. Instead of just adding a column to a table, an application developer might find themselves having to justify their case to a DBA, even if the column isn't used by any other application. The DBA might be busy responding to change requests from other teams, leaving the application developer blocked.

Chances are you've seen the shared database solution many times. It's probably the most common way of sharing data between applications (or in monolithic applications that should have been many small applications). What are some of the positive and negative experiences you've had with it?

Paul Stovell's Blog

Hello, I'm Paul Stovell

I'm a Brisbane-based software developer, and founder of Octopus Deploy, a DevOps automation software company. This is my personal blog where I write about my journey with Octopus and software development.

I write new blog posts about once a month. Subscribe and I'll send you an email when I publish something new.

Subscribe

Comments