# Why eRPC?

> Source: https://docs.erpc.cloud/why
> Main use-cases — cost reduction, fault tolerance, observability, and EVM-aware load balancing.
> Format: machine-readable markdown export of the docs page above.
> All collapsible AI sections are inlined and fully expanded.

# Why eRPC?

These are the main reasons eRPC was built:

- To **reduce overall costs** of RPC usage and egress traffic, by local caching.
- To provide a **fault-tolerant** and **reliable source** for RPC consumers in case of one or more provider outages.
- To give a global **observability** about your RPC usage both within internal teams and projects, and towards the upstream RPC 3rd party companies.

# Features

- [Score](/config/projects/upstreams.llms.txt#priority--selection-mechanism) multiple upstreams by tracking their response time, error rate, blockchain sync status, etc.
- [Failsafe](/config/failsafe.llms.txt) policies to help with intermittent issues and increase general resiliency (retries, hedging, circuit breakers).
- Offer self-imposed [rate limitting](/config/rate-limiters.llms.txt) per project, or network, or upstream to avoid abuse, and unintentional DDoS.
- Prometheus metrics collection and Grafana dashboards to [monitor](/operation/monitoring.llms.txt) costs, usage and health of your RPC endpoints.
- [Caching](/config/database/evm-json-rpc-cache.llms.txt) and multiplexing (auto-merging identical requests) to reduce redundant RPC calls and costs.
- [Integrity](/config/failsafe/integrity.llms.txt) module helps increase data quality on certain methods such as eth_getLogs or eth_getBlockByNumber.

# Use-cases

For the start the main focus of eRPC will be on read-heavy use-cases such as:

### Frontend of dApps

Often many requests made from dApps can be multiplexed into a single RPC call, or use cache to reduce costs.

Here are real production case studies where eRPC serves 8k RPS and 1B requests / month:

- 🚀 [Moonwell: How eRPC slashed RPC calls by 67%](https://erpc.cloud/case-studies/moonwell)
- 🚀 [Chronicle: How eRPC reduced RPC cost by 45%](https://erpc.cloud/case-studies/chronicle)

### Data indexing using Ponder, Graph, Envio, Flair, etc.

When using any of the web3 indexing tools you will be making lots of requests towards your RPC provider, especially during re-backfills for historical data.

eRPC can help in two main areas:

- Cache already made RPC calls (eth_getLogs, eth_call, eth_getBlockByNumber, etc)
- Rate-limit upstream pressure towards RPC nodes to avoid fatal error

### Resilient load balancer for self-hosted RPC nodes

For app-specific chains and rollups, or projects who prefer to self-host RPC nodes for performance reasons, it makes sense to use eRPC as the entry-point load-balancer.

Compared to more traditional LB solutions (ALB, K8S Services, etc) eRPC will provide EVM-focused features like:

- EVM-aware healthchecks (e.g. how many blocks behind)
- EVM-aware fallbacks (e.g. if a 4xx is because of missing block, try another upstream)
- EVM-aware method filters (e.g. certain methods to go to node A and other methods to go to node B)