Exchange-Rate Feed & Reconciliation

This is a reported example of a Ripple design prompt, and it is really two systems wearing one name. The first is a live feed: pull rates from providers, turn many noisy quotes into one number the business trusts, and hand that number to whatever is about to price a payment. The second is a correctness system: once a transfer settles on the outside world, prove that what happened matches what you promised, and repair the books when it does not. The feed is easy. The reconciliation is the half that a payments company cares about.

Read the shape of the data before drawing anything. It decides most of the design. There are only a few hundred currency pairs, so the set of current rates is tiny and changes many times a second. The history of those rates, by contrast, only ever grows, is written once and rarely changed, and gets read by audit and analytics, not by the payment path. Two datasets, opposite in every property that matters. One is small, hot, and read on the critical path. The other is enormous, cold, and read off to the side. Say that split early. Do it in the first two minutes and the storage choices fall out of it.

The Ripple angle

Ripple builds the plumbing for cross-border settlement through products like RippleNet and Liquidity Hub, so a currency rate here is the price a real transfer is booked at. If the rate you quoted drifts from the rate you settled at, someone is short money. That is why the round bends toward reconciliation rather than raw feed throughput.