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

# Infrastructure overview

> Stack, indexers, data ingestion, and hosting

This page gives a high-level view of how Alphscan is built and run — for regular users and integrators. Operational and deployment details are not covered here.

## Stack overview

Alphscan runs on **AWS** and uses:

* **API** — HTTP API (API Gateway v2) and **Lambdas** that serve the REST endpoints (tokens, chains, normalized events, system, etc.). The public API you call is this layer.
* **Database** — **PostgreSQL (RDS)** stores normalized events, API keys, tokens, address labels, chains, and other indexed data. The API and indexers read/write this database.
* **Storage** — **S3** is used for media and static assets (e.g. token list JSON). Some token and config data is served from S3 when available.
* **Cache** — **Redis** (or similar) can be used by the indexer for rate limiting or deduplication.

The **SDK** and **API reference** tabs document how to call the API; the sections below explain where the data comes from.

## Indexer

The **indexer** is a long-running process that connects to the Alephium blockchain (and any sidechains or config you use). It:

* Follows blocks and transactions.
* Extracts and normalizes events (e.g. contract calls, transfers) into a common schema.
* Writes **normalized events** and related data into PostgreSQL.

So when you call **GET /transaction/{id}/normalized/events**, the API reads from tables that the indexer has filled. The indexer can also backfill by address, token, or transaction when needed.

## Data ingestion

A **data ingestion** service (or scripts) handles:

* **Token list** — Fetching or building the token list and syncing it to the database and/or S3 (e.g. for **GET /token/all**).
* **Address labels** — Seeding or updating label mappings and metadata for addresses.
* **Other reference data** — Any static or slowly changing data that the API or indexer depends on.

This keeps token metadata, labels, and similar data up to date without blocking the main indexer.

## Job processor (reindexer)

A **job processor** (reindexer) runs background jobs: for example, reindexing a range of blocks or processing user-triggered tasks. Jobs are stored in the database; the processor picks them up and updates the same PostgreSQL data the API reads. Admin endpoints like **GET /system/jobs** list these jobs.

## Status and uptime

We use a public status page so you can see the current state of the API and related services:

**[Alphscan / Alephium status — status.babypooltool.com](https://status.babypooltool.com/status/alephium)**

Check it for incidents, scheduled maintenance, and uptime. If the API is slow or returning errors, the status page is the first place to look.

## Hosting (high level)

* **API and Lambdas** — Run on **AWS** (API Gateway + Lambda). The public base URL (e.g. `https://api.alphscan.io`) is fronted by a custom domain with SSL; traffic is routed to API Gateway and then to the appropriate Lambda.
* **Database** — PostgreSQL is hosted on **AWS RDS**. Read replicas can be used for the API to spread read load.
* **Stages** — We use stages (e.g. **dev**, **prod**) so production and development use separate API stages and, when desired, separate databases or resources.

For exact regions and deployment steps, refer to the project’s internal ops or deployment docs. For **using** the API, the [API reference](/api-reference/introduction) and [Quickstart](/quickstart) are the right entry points.

<Card title="Status page" icon="signal" href="https://status.babypooltool.com/status/alephium">
  Check Alephium / Alphscan status and uptime.
</Card>