Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Married Couple Component Design Pattern

DZone's Guide to

The Married Couple Component Design Pattern

Multi-node components and services that require consensus can be tricky beasts to handle. Read on for some insight on how you may want to handle such situations.

· Database Zone ·
Free Resource

RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.  

One of the tough problems in distributed programming is how to deal with a component that is made up of multiple nodes. Consider a reservation service that is made up of a few nodes that needs to ensure that regardless of which node you’re talking to, if you make a reservation, you’ll have a spot. There are a lot of ways to solve this from the inside, but that isn’t what I want to talk about right now. I want to talk about the overall approach to modeling such systems.

Image title

Instead of focusing on how you would implement such a system, consider this to be an internal problem for this particular component. A good parallel for this problem is making plans with a couple for a meetup. You might be talking to both of them or just one, but you don’t care. The person you are talking to is the one who is going to giving you a decision that is valid for the couple.

How they do that is not relevant. It may be that one of them is in charge of the social calendar or that they switch based on the day of the week or whoever got out of bed first this morning or whatever his mother called her dog last year or… you don’t care. Furthermore, you probably don’t want to know. That is an internal problem and sticking your nose into the internal decision making is a bad idea that may lead to someone sleeping on your couch for an indefinite period of time.

But — and this is important — you can talk to either one of them and they will make such a decision. It may be something in the order of, “Let me talk to my significant other and I’ll get back to you by tomorrow,” or it may be, “Sure, how about 8 PM on Sunday?” or even “I don’t like you, so nope, nope, nope,” but you’ll get some sort of an answer.

Taking this back to the distributed components design, that kind of decision in internal to the component, and the mechanics of this are handled internally shouldn’t be exposed outside. Let’s take a look at why this is the case.

Starting out, we run all such decisions as a consensus that required a majority of the nodes. But a couple of nodes went down and took down the system down a bad path, so the next iteration, we had moved to reserving some spots for each node that they own and can hand off to others on their own without consulting any other nodes. This sort of change shouldn’t matter to callers of this component, but it is very common to have outside parties take notice of how you are doing things and take a dependency on that.

The main reason I call it the married couple design problem is that it should immediately cause you to consider how you should stay away from the decision-making there. Of course, if you don’t, I’m going to call your design the mother-in-law architecture.

Aggregations provide vital intelligence to the success of a business. Crush the challenge of providing real time aggregations for daily, weekly, and monthly totals without having to tie up your servers.

Topics:
database ,design patterns ,components ,database systems ,distributed progrmaming

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}