Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We (a contractor, actually) are implementing an off the shelf system to replace a legacy homegrown system for the core domain of the company (designing widgets). Unfortunately both systems will have to run concurrently for some time, as the product just isn't ready yet. Also, the decision was made to only migrate some of the widgets from the legacy system, based on date of last sale activity.

Later on a new requirement came down: certain people in the company, most of them outside of the widget development context, want to search all widgets. The search results screen has 3 pieces of data: a GUID, a human readable id that is searchable, and a brief description (may need to be searchable in the future). In the widget details, there will be multiple screens. These screens align very well along SOA / bounded context lines - a screen for marketing data, a screen for sales history, etc.

UML ahead! I am probably using the wrong kind of arrows here so please forgive me. The current solution - which is not in production yet - is something like the following:

Current Solution

Both systems will be queried and the controller will merge the results.

The new system has its own proprietary query language (we've alleviated this a bit with a LINQ provider). It also puts a lot of data on the wire. 15 search results typically run about 60k of unintelligible SOAP-wrapped xml. So I would prefer to avoid querying this system directly.

These two systems publish events to help us integrate with other systems, mainly an ERP system. One of these events contains all the data necessary for the search screen. I proposed the following alternative:

Proposed Solution

However I am being told that 'adding another database' will create more maintenance down the road. However, I believe this to be false, as I had to add a relatively simple feature that took several hours longer than anticipated because of this merging code.

I want to get a feel for which system is more maintainable in the long run. I personally have not had the burden of maintaining any large system. I want something more than my gut. Specifically I'd like to know if having more, specialized physical databases is more or less maintainable than having less larger physical databases.

share|improve this question
    
The easier you make it for people to use both systems in parallel, the harder it will be for you to kill of that legacy system. The simplest solution has one box - "new system". –  Dan Pichelman Jul 2 '13 at 17:23
    
@DanPichelman: A laudable goal, but unfortunately one that is not always realistically achievable. –  Robert Harvey Jul 2 '13 at 17:33
    
    
I agree with moving everyone over at once. BUT the main driver of the new system wants it now, before it is ready. Business requirements trump geek requirements. :) Also, I would prefer to avoid querying this new system directly; as I said it is extremely (almost purposefully) inefficient. –  user408866 Jul 2 '13 at 17:53
add comment

1 Answer

The 'search database' introduces an additional point of failure in the total system, and the failures introduced there might go unnoticed for a very long time.

The problem that I see is that the 'search database' might miss or otherwise fail to process a widget_event and get out of sync with the two sub-systems that it provides a front-end for. Such an inconsistency will happen in the long run and won't be noticed until someone notices a particular widget being missing from the search results, while it is known to be present.

The 'search database' could work if you design it such that it periodically performs a full synchronization with the back-end systems, but then the added value diminishes to nearly zero, because you haven't skipped out on the queries to the back-end systems, while you still need to maintain an additional system.

share|improve this answer
    
These are all very good points! However can mitigate these problems with the following: 1) the search database will likely be hosted on the same database server as the legacy system's database. 2) At least once delivery e.g. RabbitMQ - the handling of the message in this context is idempotent. We will probably use this: bit.ly/19TC9pM (example implementation here: bit.ly/12GHJW2). 3) we already have robust logging in our messaging infrastructure. –  user408866 Jul 3 '13 at 15:03
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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