> ## Documentation Index
> Fetch the complete documentation index at: https://algolia.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Servers and clusters

> Learn about Algolia's classic infrastructure that runs on bare-metal servers.

export const SearchRequest = () => <Tooltip tip="A search request is a single HTTP call to the Algolia Search API that can run one or more search operations. It can include multiple queries, for example, when querying several indices at once.">
    search request
  </Tooltip>;

export const Application = () => <Tooltip tip="An Algolia application is a self-contained environment with its own indices, configuration, and API keys. Applications don't share data or settings with each other.">
    application
  </Tooltip>;

Algolia's classic infrastructure runs directly on the hardware without virtualization.
This is sometimes called bare metal.

When you create a new Algolia <Application /> with the Build, Grow, and Premium plans,
it'll be hosted on classic infrastructure.
For more information, see [Pricing](https://www.algolia.com/pricing/).

## Clusters

Your application is hosted on a **cluster of three identical servers.**
This ensures a **high availability**:
if one or two servers go down, your users can still search,
while indexing operations are paused until all three servers are online again.
For more information see [Availability over consistency](#availability-over-consistency).

Having three copies of your data also makes data recovery easier if there's a hardware failure.

**This redundancy guarantees an SLA of 99.99% availability.**

### Resiliency

**To increase resiliency** of your clusters,
Algolia implements geographical and network redundancies:

* To prevent incidents, such as fires or floods, from bringing down the entire cluster,
  Algolia separates the servers into different data centers.
* To prevent network failures,
  no server within the same cluster uses the same internet service provider.

### Consensus

All three servers in a cluster have the same data.
To prevent inconsistencies, Algolia uses the [Raft algorithm](https://raft.github.io/)
to ensure that all servers in a cluster update simultaneously.
This ensures that each server always has the same data without service interruption.

### Scaling beyond clusters

By default, your Algolia application shares a cluster with other applications.
You can request dedicated infrastructure as an add on.
For more information, see [Pricing](https://www.algolia.com/pricing/).

You can add more servers to your cluster.
This adds capacity to handle search requests,
and reduces network latency if you add servers in a region closer to your users.
For more information, see [Distributed Search Network](/doc/guides/scaling/infrastructure/classic/distributed-search-network-dsn).

For more information,
see [Large indexing jobs](/doc/guides/scaling/scaling-to-larger-datasets).

## What happens when a server goes down

Servers may fail to respond for a number of reasons:

* Temporary network issues
* High server load
* Hardware failures

If a server goes down, Algolia handles search and indexing requests differently.

### Search requests

If one or two servers go down,
the others will still handle search requests **without interruption**.
For search, consistency is less important.
As long as one server is able to handle the <SearchRequest />,
your users still get search results.

### Indexing requests

While one server might be unreachable to the other servers within the cluster,
it might still receive requests from the outside.
In that case, the other two servers continue handling requests,
finding consensus among themselves.
On unreachable servers, **indexing jobs are queued**.
If the third server becomes reachable again, it can synchronize with the other two.

## Availability over consistency

Hosted services need to find a balance between:

* **Availability** guarantees constant access to your data without service outage.
* **Consistency** guarantees the same data everywhere at the same time,
  for example, all users get the same search results simultaneously.

For more information, see [CAP theorem](https://wikipedia.org/wiki/CAP_theorem) and [eventual consistency](https://wikipedia.org/wiki/Eventual_consistency).

**Algolia chooses availability over consistency.**

Because when users search, they should always get results.
This is more important than small differences between searches.
Under normal load, synchronizing data between three servers takes seconds or less,
so that you only infrequently experience data discrepancies.

That's why all three servers in a cluster respond to search requests,
so that at least one server is always available.
If Algolia were to delay search requests until all three servers have the same data (consistency),
it might cause large delays, leading to an unresponsive search.

### Location of Algolia infrastructure (classic)

When you create new Algolia applications with classic infrastructure,
you can choose a region where your new application will be hosted.
Some regions aren't available for all plans.
For more details, see [Pricing](https://www.algolia.com/pricing/).

| Region                   |          | Notes                                                                                                        |
| ------------------------ | -------- | ------------------------------------------------------------------------------------------------------------ |
| **US-East** (Virginia)   |          | 2 different Equinix data centers in Ashburn & COPT DC-6 in Manassas (3 independent, autonomous systems       |
| **US-West** (California) |          | 3 different Equinix data centers in San Jose (3 independent, autonomous systems)                             |
| **US-Central** (Texas)   |          | 2 different data centers in Dallas (2 independent, autonomous systems)                                       |
| **Europe** (France)      |          | 4 different data centers in Roubaix, 2 different data centers in Strasbourg, and 1 data center in Gravelines |
| **Europe** (Netherlands) | DSN only | 4 different data centers around Amsterdam                                                                    |
| **Europe** (Germany)     |          | 7 different data centers in Falkenstein and 1 data center in Frankfurt (2 independent, autonomous systems    |
| **Europe** (UK)          |          | 2 different data centers in London (2 independent, autonomous systems)                                       |
| **Canada**               |          | 4 different data centers in Beauharnois                                                                      |
| **Middle East**          | DSN only | 1 data center in Dubai                                                                                       |
| **Singapore**            |          | 2 different data centers in Singapore (2 independent, autonomous systems)                                    |
| **Brazil**               |          | 3 different data centers around São Paulo (2 independent, autonomous systems)                                |
| **Japan**                |          | 1 data center in Tokyo and 1 data center in Osaka                                                            |
| **Australia**            |          | 3 data centers in Sydney (2 independent, autonomous systems)                                                 |
| **India**                |          | 1 data center in Noida                                                                                       |
| **Hong Kong**            |          | 2 different data centers (2 independent, autonomous systems)                                                 |
| **South Africa**         |          | 2 data centers in Johannesburg (2 independent, autonomous systems)                                           |