The importance of database isolation

This week I've continued to progress on the new project.

One of the worries that has been roaming my head was the isolation of data between different components. On the current concept, components are isolated from each other to some extent but they still share some common resources like the database.

Below is a simple diagram that depicts the difference between shared and isolated approaches to database storage (credits to Mary Taylor @ IBM).

It was a relevant point to ensure that this resource would also stop being shared for the following reasons:
  • One faulty component could wreck the database, causing other components to also fail
  • 10 components can share a single database, could 100 or even 1000 use the same model?
  • No duplicate table names on the database could exist, this issue is aggravated when sharing this resource with other components
  • One single point of failure, if the database goes offline then all others will also fail to recover themselves

And some advantages also surfaced:
  • Each component can define custom login/passwords to access their database
  • Full control over the data that is stored, no other components change the data by accident
  • Provides choice between running their HSQL database based on a disk file for optimum storage or stored in volatile RAM for optimum speed
  • Each component can now individually store up to 16Gb of data using HSQL

I suspected that transitioning from a shared database model onto an isolated model would be somewhat troublesome, but the implementation was (fortunately) completed in a half a day and the effort was surely worthwhile. The end result passed all test cases and works exactly as intended.

Lesson learned:

When designing/implementing an architecture, do take into consideration the importance of keeping these resources isolated from each component as early as possible. In the long run you are improving the robustness of the system that is being designed.

No comments:

Post a Comment