A hub-and-spoke architecture is an architectural _topology_ (or [[Pattern]]) wherein many components of a system are all linked to one-another via a central hub. This, in effect, promotes the hub to being the **main** and **most important** aspect of the system. For any system of notable size, a hub-and-spoke architecture will have achieve the net effect of _lowering the total number of integrations needed_ for a fully-connected system: ![[Pasted image 20240908103406.png]] This trend grows exponentially: | Number of Components | Hub-and-Spoke Integrations | Point-to-Point Integrations | | -------------------- | -------------------------- | --------------------------- | | 2 | 2 | 1 | | 3 | 3 | 3 | | 4 | 4 | 6 | | 5 | 5 | 10 | | 6 | 6 | 15 | | 7 | 7 | 21 | In general, `N` components creates `N` integrations in a hub-and-spoke architecture, and `sum of all numbers up to N` integrations in a point-to-point architecture. # Pros - [[Modularity]] - hub-and-spoke makes the system more likely to be [[Highly Cohesive, Loosely Coupled]] - [[Structure Removes Decision Fatigue]] - Greater importance placed on the central system gives a natural place to apply _governance_ and other such business desires, rather than deciding on a case-by-case basis where they should be applied - Business rules and situation-based or event-based algorithms can run in the hub (or be attached to the hub) with a full picture of the system - at which point the hub is referred to as a [[Broker]] # Cons - **Many eggs, one basket** - if you don't build your own hub, someone has you over a barrel - **Foregoing native connections** - some things are designed to work well together directly. By forcing communication through the hub, you're inserting overhead. - Not everything in a system typically _needs_ to be connected to everything else **** ## Source - I'm writing this from the top of my dome, but have read about it in many places that should be here & aren't ## Related