Data Repli­ca­tion in SOA: The Price of Loose Cou­pling

When de­sign­ing a cor­po­rate SOA ar­chi­tec­ture you are of­ten faced with a tough choice: do you rely on a com­mon data­base (cen­tral­ized) or do you im­ple­ment repli­ca­tion in­stead?

Let me ex­plain what I mean. The idea in SOA is that you de­fine more or less in­de­pen­dent ser­vices that cor­re­spond (hope­ful­ly) to clear­ly de­fined and busi­ness-re­lat­ed ac­tiv­i­ties. For in­stance, you could have a cus­tomer man­age­ment ser­vice and a pay­ment/in­voic­ing ser­vice. The cus­tomer man­age­ment ser­vice be­longs to CRM, the in­voic­ing to the billing de­part­ment. How­ev­er, both of these ser­vices might need the same cus­tomer data. Now what do you do? Ba­si­cal­ly, you have the fol­low­ing op­tions:

1. Use the same cen­tral­ized cus­tomer data­base. This gives you the ben­e­fit of easy main­te­nance be­cause there is only one copy. How­ev­er, this also means that you are cou­pling your ser­vices into the same data­base schema, and up­dates to the schema are like­ly to af­fect more than one ser­vice.
2. Repli­cate the cus­tomer data­base, by iden­ti­fy­ing one mas­ter (the CRM?) that reg­u­lar­ly push­es or pub­lish­es up­dates (in an XML feed, for in­stance). While you lose the ben­e­fit of easy main­te­nance, this does give you loose cou­pling: as long as the XML for­mat is the same, you can change DBMS schemas as much as you like - with­out af­fect­ing oth­er ser­vices.
3. Merge the cus­tomer and in­voic­ing ser­vices into one. How­ev­er, this may not al­ways be pos­si­ble or de­sir­able, and may even de­feat the pur­pose of ser­vice-ori­ten­ta­tion al­to­geth­er.
4. Have the in­voic­ing query the cus­tomer ser­vice for each pay­ment. Thi seems to in­cur a lot of de­pen­den­cies and net­work traf­fic.

So what do you do? My pref­er­ence tends to go to the sec­ond op­tion. How­ev­er, it means that re­al­is­tic SOA ar­chi­tec­tures are like­ly to have an event-dri­ven na­ture.