We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Data Replication Distribution
Free preview: the first 2 parts of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Data Replication Distribution
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
FedEx doesn't ship a package directly from Boise, Idaho to a small town in Vermont. It flies the package to its hub in Memphis, sorts it, and then routes it to the destination. Every package flows through the hub. It's less efficient for point-to-point delivery, but it massively simplifies routing and logistics.
Hub-and-spoke follows the same model. A central "hub" database receives all changes and distributes them to regional "spoke" databases. Spokes don't talk to each other directly. All communication flows through the hub.
This topology dominated enterprise data architecture for decades, and it's still widely used today. Multinational corporations with offices in New York, London, Singapore, and Sydney often run a hub database in their primary data center with spokes in each regional office. Walmart replicates inventory and pricing from headquarters to its 10,500+ stores worldwide using a hub-and-spoke model. Oracle GoldenGate, IBM InfoSphere, and Microsoft's merge replication all support this pattern natively.
It's not the most technically clean solution, but it's operationally simple and well-understood. When the CTO asks "how does data get from our Sydney office to our London office?" the answer is straightforward: it goes through the hub.
The structure has two tiers:
The hub. A central node that holds the complete, authoritative dataset. All writes ultimately flow through the hub. It's responsible for distributing changes to all spokes.
The spokes. Regional or departmental nodes that hold a copy (full or partial) of the hub's data. Depending on the configuration, spokes may be read-only or may accept local writes that are sent back to the hub for distribution.
Data flow patterns:
Hub-to-spoke (top-down). Hub pushes changes to spokes. This is the simplest pattern. The hub is the single source of truth, spokes are read-only consumers. Product catalogs, pricing tables, and reference data typically flow this way.
Spoke-to-hub (bottom-up). Spokes send local data back to the hub. Sales transactions at a retail store flow up to headquarters. The hub aggregates and redistributes.
Spoke-to-spoke (via hub). If the London office needs data from the Sydney office, it goes Sydney spoke to hub to London spoke. Spokes never communicate directly.
| Data Flow | Example | Direction | Typical |
|---|---|---|---|
| Product catalog | Hub to all stores | Hub to spoke | 1-5 seconds (CDC) |
| Store sales data | Each store to HQ | Spoke to hub | Batch every 5-60 minutes |
| Cross-region report | Via hub | Spoke to hub to spoke | Double the single hop |