Summary

• Subtracted on a per-request basis.
• Tracked over a sliding 5-minute window.

Requests to Aptos Build APIs are measured in terms of Compute Units (CUs). CUs measure the relative cost of a request on our infrastructure. For example, a given call to /v1/accounts/0x1 (the Node API) might cost 250 CUs while a call to /v1/graphql (the Indexer API) might cost 500 CUs, indicating that the nfra cost of the second request is 2x higher than the first. Compared to just rate limiting based on request count, Compute Units allow us to capture that some requests are more resource intensive than others.

Compute Unit Calculation

The method for calculating the CUs used by a request differs per upstream type (e.g. Node API vs. Indexer API) and endpoint (e.g. /v1/view vs. /v1/accounts), but as a general rule of thumb, the more complex a request is (gas used, time taken, etc.), the more CUs it will consume. We use a variety of factors to calculate the cost of a request, and our approach is subject to change at any time. Broadly speaking, the behaviour is as described below.

Node API

The current approach for this upstream is quite simple.

In other words, cost is just a function of how long the upstream takes to process the request. In general, node API requests are dominated by I/O time on the database. The more complex a query is, the longer it takes, the higher the cost in CUs.

Expensive, long running queries have an outsized impact on our infrastructure, so we scale the cost exponentially.

Node API (VM Endpoints)

Requests to endpoints that involve execution with the Move VM (e.g. /v1/transactions/simulate or /v1/transactions/view) return the cost of that execution in terms of gas. We use this gas cost and some multiplier to get the final gas cost:

Indexer API (Other Endpoints)

We use the same formula as with the Node API, albeit with different multipliers.

Summary

• There is a maximum number of streams that can be active concurrently.

For streaming services, such as the Transaction Stream Service, each organization is allowed a certain number of concurrent streams. Each time a client opens a new GRPC stream, it counts against the limit for the project.

If you hit this limit, you will receive a 429 if you try to open a new stream.

Summary

• Tracked on a monthly basis.
• Quota is topped up at the end of the month.
• Use it or lose it, unused quota at the end of the month does not roll over.
• Transaction credits are only consumed if the transaction succeeds on chain.

For Gas Station and Token Management Platform, each organization pays for a certain quota of transaction credits. Each transaction that is sponsored by a Gas Station and succeeds on chain consumes a certain number of credits.

As with other quotas, to ensure that one particular project can’t use all the quota, you can put limits in place on the amount of transaction credits that can be consumed by that project.

Summary

• There is a maximum number of processors an organization can create.
• Processors will be halted if they hit their DB space limit.
• Indexing will fall behind if a processor hits its write throughput limit.
• Requests to the API created for the processor are tracked with CUs.

Because a single processor is composed of multiple pieces of infrastructure, and the load varies based on multiple factors, we use a combination of quotas to track usage for no-code indexing.

Number of processors

Each organization is allowed a certain number of processors. You cannot create a new processor without first deleting an existing one if you have hit this limit. In-place upgrades do not count against this quota (since there is no new processor created). Hard upgrades count as new processors, and therefore count against this quota.

DB space

Each organization is allowed a certain amount of disk space for indexing. For example, 500GiB. As with all quotas, you can allocate this between your processors. If your processor hits this limit, it will be paused (just like if you had paused the processor yourself through the UI). In this case, it will not index new events, but the API will continue to serve queries.

This is a static quota, it is not a sliding window and it does not reset at certain time intervals. You must upgrade your plan if you are close to running out of space.

Write Throughput

To ensure a single processor doesn’t use up too much of the query-handling capacity of the indexing infrastructure, we limit the amount of data written to the database by each processor. If a processor hits a certain limit, it will naturally lag behind the head of the chain.

This is measured in terms of bytes written by the processor per 5 minutes. Both INSERTS and UPSERTS count towards this limit, the purpose of this limit is to protect the DB’s CPU, not its disk space.

This is tracked with a sliding 5-minute window.