Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How do you update multiple disparate databases?

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Ask HN: How do you update multiple disparate databases?

#31

Post by chrisacky »

PaulRobinson wrote: post #26
perlgeek wrote: post #22

So, the first solution to consider is if this needs a technical solution at all. If it happens infrequently enough, you can have simply have a proceed "change mortgage rate" that touches the 4 legacy databases. Done. If it does need a technical solution, you have to establish the leading system / source of truth / whatever you call it. This can be either an existing system or a new one. And then all the others need t…

There might be an addendum to this good answer: OP seems to be thinking they all need to show the same rates at the same time, so in essence you're looking for a "distributed transaction", which, as we all know... well, exercise for the reader and all that. However, one technique I've used which works with all your approaches and guarantees consistency if the data model allows it is to have "future value" entries. If…

> This seems really obvious once you've seen it

I think that's true for 90% of patterns/problems in dev. Did you see that Prince of Persia post the other day? How the original creator came up with Shadow Man? Kind of resonates with what you are getting at in being obvious.

I embarrassingly have a 8 year old top StackOverflow post asking what a fluent interface was. Keeping in mind I'd been devving for 5+ years already at that point. It was just a "ahh F* yeah, that's obvious" moment.

Re: Ask HN: How do you update multiple disparate databases?

#32

Post by edoceo »

Oh, I've done this. The 4DBs are for forward-origination, servicing and reverse origination, servicing.

We had a prime app, a fifth DB driving it. It had scripts to pull rates and a UI to adjust. Logs all changes.

These rates are pulled by the other systems (eg the AS400 pulled over FTP). Additional internal apps could query over SMB and HTTP.

The prime updated slowly and each of the services would poll it very frequently (4m) + on-demand when needed

Re: Ask HN: How do you update multiple disparate databases?

#33

Post by Misdicorl »

Misdicorl wrote: post #30

Step 1) Generate a GUID Step 2) Send a message to all the `downstream` systems (i.e. not the Source of Truth systems) with the change description and GUID Step 3a) Update source of truth with the new info, write the GUID to a log table in source of truth in the same transaction Step 3b,c,d) Downstream systems poll the source of truth for existence of the GUID in the log table indicating the change has been committed…

Note that downstream systems can skip updates with this system, but will always be eventually consistent. Buyer beware

Re: Ask HN: How do you update multiple disparate databases?

#34

Post by xnxn »

chrisjc wrote: post #14
redis_mlc wrote: post #2

Banks use an ancient but powerful architecture called Source of Truth (SoT), or system of record. It's one of the first techniques developed to manage heterogeneous distributed databases. One master is picked as the final authority, then changes flow to other databases, replicas, etc. either using database tools or applications. Awareness of deadlines or how much latency (ie. when the updates are needed for each down…

> A practical example that solves a simple case is the recent release of a tool by Netflix. Which tool is this?

DBLog: https://netflixtechblog.com/dblog-a-generic-change-data-capt...

Re: Ask HN: How do you update multiple disparate databases?

#35

Post by TimSchumann »

Misdicorl wrote: post #30

Step 1) Generate a GUID Step 2) Send a message to all the `downstream` systems (i.e. not the Source of Truth systems) with the change description and GUID Step 3a) Update source of truth with the new info, write the GUID to a log table in source of truth in the same transaction Step 3b,c,d) Downstream systems poll the source of truth for existence of the GUID in the log table indicating the change has been committed…

This seems entirely reasonable, but you forgot the 0'th step.

Create a source of truth. I'd bet a 'source of truth' internal to the bank doesn't exist right now, and they're probably pulling something manually from an external 3rd party.

And on with the regress..

Step -1) What form will this internal source of truth take, how much will it cost, and who builds that system?

Step -2) Who gets to make that decision?

My uncle used to do this kind of work and man, he has some horror stories. The common thread among his clients seemed to be 'We know we need to do something, we know it will cost a lot of time and money, and it absolutely cannot fail.' The hard part always seemed to be finding the person within the org who had both the authority to spend the money, the political clout to make the decision. Nobody wants to own something like that going wrong. The actual technical part of the work, they had that down pretty well as it was all they did.

Re: Ask HN: How do you update multiple disparate databases?

#36

Post by mceachen »

rorykoehler wrote: post #15
redis_mlc wrote: post #2

Banks use an ancient but powerful architecture called Source of Truth (SoT), or system of record. It's one of the first techniques developed to manage heterogeneous distributed databases. One master is picked as the final authority, then changes flow to other databases, replicas, etc. either using database tools or applications. Awareness of deadlines or how much latency (ie. when the updates are needed for each down…

I was in a client meeting a while back where one of their consultants corrected me with 'system of record' when I said source of truth. Your comment made me wonder where this distinction/difference was from? Do you know the history behind this?

FWIW I've heard both used interchangeably (in banking, adtech, and other tech verticals).

Edit: the linked wikipedia articles discriminate the terms by defining SSOT as a single place to store and edit every data element, while SOR allows for replicas, but in the case of data discrepancies, the SOR's state wins.

Re: Ask HN: How do you update multiple disparate databases?

#37

Post by girzel »

smacktoward wrote: post #23
maps7 wrote: post #20

Earlier quoted context omitted.

It's probably just what they call it.

I have no idea about this particular case, but for a lot of older concepts the root of divergent terminology is IBM. IBM invented its own lingo for lots of things, and persisted in using it even when the rest of the world settled on a different term. (This seems to be a habit companies pick up when they become huge and dominant; see also Micro-speak and Google-speak.) The thing everybody else called a "hard disk," fo…

Cf Emacs' "windows", "frames", "kill", "yank", etc...

Re: Ask HN: How do you update multiple disparate databases?

#38

Post by atwebb »

rorykoehler wrote: post #15
redis_mlc wrote: post #2

Banks use an ancient but powerful architecture called Source of Truth (SoT), or system of record. It's one of the first techniques developed to manage heterogeneous distributed databases. One master is picked as the final authority, then changes flow to other databases, replicas, etc. either using database tools or applications. Awareness of deadlines or how much latency (ie. when the updates are needed for each down…

I was in a client meeting a while back where one of their consultants corrected me with 'system of record' when I said source of truth. Your comment made me wonder where this distinction/difference was from? Do you know the history behind this?

It totally depends on the instance:

Was it a piece of atomic data at the system of generation? Likely SoR

Was it an aggregated/mastered/other data? Likely Source of Truth

SoR = Where it came from

SoT = Where you get it from

Re: Ask HN: How do you update multiple disparate databases?

#39

Post by mey »

TimSchumann wrote: post #35
Misdicorl wrote: post #30

Step 1) Generate a GUID Step 2) Send a message to all the `downstream` systems (i.e. not the Source of Truth systems) with the change description and GUID Step 3a) Update source of truth with the new info, write the GUID to a log table in source of truth in the same transaction Step 3b,c,d) Downstream systems poll the source of truth for existence of the GUID in the log table indicating the change has been committed…

This seems entirely reasonable, but you forgot the 0'th step. Create a source of truth. I'd bet a 'source of truth' internal to the bank doesn't exist right now, and they're probably pulling something manually from an external 3rd party. And on with the regress.. Step -1) What form will this internal source of truth take, how much will it cost, and who builds that system? Step -2) Who gets to make that decision? My u…

It's amazing how hard the "system of record" conversation can be.
Post reply on HN