# High Availability

## Reader Node

Placing multiple [Reader Node](/firehose/architecture/components/reader.md) components side by side, and fronted by one or more Relayers, allows for highly available setups; a core attribute of the Firehose design.

A Relayer connected to multiple Readers will deduplicate the incoming stream and push the first block downstream.

{% hint style="success" %}
***Tip**: Two Reader Node components will even race to push the data first. The system is designed to leverage this racing* [*Reader Node*](/firehose/architecture/components/reader.md) *feature to the benefit of the end-user by producing the lowest latency possible.*
{% endhint %}

### Data Aggregation

Firehose also aggregates any forked blocks that would be seen by a single Reader Node component, and not seen by any other [Reader Node](/firehose/architecture/components/reader.md) components.

### Component Cooperation

Adding Reader Node components and dispersing each one geographically will result in the components actually racing to transfer blocks to the Relayer component. This cooperation between the [Reader Node](/firehose/architecture/components/reader.md) and [Relayer](/firehose/architecture/components/relayer.md) components *significantly* increases the performance of Firehose.

## Merger

A single [Merger](/firehose/architecture/components/merger.md) component is required for Reader Node components in a highly available Firehose.

Highly available systems usually connect to the [Relayer](/firehose/architecture/components/relayer.md) component to receive real-time blocks. Merged blocked files are used when Relayer components can't provide the requested data or satisfy a range.

Restarts from other components can be sustained and time provided for [Merger](/firehose/architecture/components/merger.md) components to be down when Relayer components provide 200 to 300 blocks in RAM.

{% hint style="info" %}
**Note***: Merged blocks generally aren't read by other Firehose components in a running, live highly available system.*
{% endhint %}

## Relayer

A [Relayer](/firehose/architecture/components/relayer.md) component in a highly available Firehose will feed from all of the Reader Node components to gain a complete view of all possible forks.

{% hint style="success" %}
**Tip***: Multiple* [*Reader Node*](/firehose/architecture/components/reader.md) *components will ensure blocks are flowing efficiently to the* [*Relayer*](/firehose/architecture/components/relayer.md) *component and throughout Firehose.*
{% endhint %}

## Firehose gRPC Server

Firehose can be scaled horizontally to provide a highly available system.

The network speed and data throughput between consumers and Firehose deployments will dictate the speed of data availability.

{% hint style="info" %}
**Note***: The network speed and data throughput between* [*Relayer*](/firehose/architecture/components/relayer.md) *components and* [*Firehose gRPC Server* ](https://github.com/streamingfast/firehose-docs/blob/master/architecture/components/grpc-server.md)*components will impact the speed of data availability.*
{% endhint %}

Firehose [gRPC Server](https://github.com/streamingfast/firehose-docs/blob/master/architecture/components/grpc-server.md) components have the ability to connect to a subset of Relayer components or all Relayers available.

When the Firehose [gRPC Server](https://github.com/streamingfast/firehose-docs/blob/master/architecture/components/grpc-server.md) component is connected to all available Relayer components the probability that all forks will be viewed increases. Inbound requests made by consumers will be fulfilled with in-memory fork data.

Block navigation can be delayed when forked data isn't completely communicated to the Firehose [gRPC Server](https://github.com/streamingfast/firehose-docs/blob/master/architecture/components/grpc-server.md) component.

Understanding how data flows through Firehose is beneficial for harnessing its full power.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://firehose.streamingfast.io/firehose/architecture/components/high-availability.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.