# Why do we need sharding?

[Using bots](https://github.com/enoki-dex/enoki_wrapped_token/tree/main/benchmarks/benchmark_transactions) trading DIP-20 tokens on the Internet Computer **mainnet**, we have determined that having more than about 150 users simultaneously trying to send traditional tokens will result in significant delays and timeouts, requiring users to continuously retry their transactions until they are successful.

![](/files/p6kkdRrBnUULlHSn14a8)

Bots tried to execute 1 transaction each, all at the same time. If there was an error, each bot retried after 1-4 seconds.

Starting at around 150 concurrent users, there are minor inconveniences: a few rejected calls that need to be retried and \~4-20 second delays.

However, starting at around 750 concurrent users, the transaction backlog starts to pile up, and transaction times start to grow exponentially into the minutes.

These results on mainnet are also consistent with tests on a local replica, which also determined that transactions were unfeasible starting at around 1,000 concurrent users.

### How do we solve this scalability problem?

While this problem can be somewhat incrementally diminished as the Internet Computer scales up individual throughput to its subnets, there will still be a limit to how many users can transact at the same time. The problem is that all transactions have to be processed sequentially in order to avoid double spending.

To solve this problem, and also to take advantage of the Internet Computer's "infinite scalability", we assign users to different shards, and shards communicate with themselves as described in the next section.


---

# 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://docs.enoki.ooo/fundamentals/why-do-we-need-sharding.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.