# Federated Repositories

|     |
| --- |
|  |

The federated repositories pattern builds off of the [Bi-Directional Proxying](https://help.sonatype.com/en/bi-directional-proxying.html "Bi-Directional Proxying") pattern. As with bi-directional proxying, the geographically separated teams may only share portions of what they create (e.g., perhaps they don't share their Maven components but only the finished wars/Docker containers).

The example above comprises three separate teams in three separate regions. There is bi-directional proxying between regions A and B; regions A and C; and regions B and C. To zoom in and see what bi-directional proxying looks like between each of these regions, see the [Bi-Directional Proxying](https://help.sonatype.com/en/bi-directional-proxying.html "Bi-Directional Proxying") pattern.

This pattern allows for teams in different regions to proxy content from another region on-demand.

## Combines With

This pattern extends the [Bi-Directional Proxying](https://help.sonatype.com/en/bi-directional-proxying.html "Bi-Directional Proxying") pattern

## Problems Addressed

- Bi-directional distribution for geographically separated teams
- Some content is used only within one region, some is distributed

## Prerequisites

- High-bandwidth, low-latency network connection between sites

## Factors to Consider

- Must maintain corresponding repository structures between sites
- Configuration can be complex with many sites and formats
- Can increase network traffic and latency
- Consider resiliency and recovery separately for each region
- Must manage cleanup independently by region; this can add complexity
- Must manage user tokens and access controls independently by region

## Available Resources

The following help topics may be helpful when implementing this pattern:

- [Scaling with Proxy Nodes](https://help.sonatype.com/en/scaling-with-proxy-nodes.html "Scaling with Proxy Nodes")
- [Repository Management](https://help.sonatype.com/en/repository-management.html "Repository Management")