AZ Lamps #19 — Cosmos DB Burst Capacity
Despite AI-related titles foregrounded during the Microsoft Build 2023, many other engaging announcements appeared. Today I want to draw your attention to the Burst Capacity in Azure Cosmos DB.
Azure’s proprietary database differs from traditional relational databases, not only because it is NoSQL. Its performance is measured with an artificial metric called Request Units (RU), where 1 RU is the cost of reading a 1 Kb document by its ID (to be precise, combining an ID and a PartitionKey). The more complex the request is, the more RU it costs: an update is more expensive than a read, and a read using “like” is more expensive than a point read. Worth noting that running operations in parallel doesn’t increase the cost of individual CRUDs, so the total cost is a simple sum of RUs with no extra fees.
When designing, it is crucial to calculate how many RUs per second (RU/s) the system needs. I do that with a calculator provided by Azure — it simplifies the process so I get a result, for example, 100 RU/s. I will again emphasize that this number determines database throughput and cost.
If you exceed the specified limit, Cosmos returns the 429 error (Too Many Requests). For this reason, existing codebases almost always implement a custom retry logic in the database layer. But the Burst Capacity might be a game changer.
The feature allows accumulating the unused RUs. For example, if a 100 RU/s database remains idle for 5 minutes, it collects 100 RU/s x 300 seconds = 30 000 additional RUs. You may spend this extra capacity at a maximum speed of 3000 RU/s, increasing the base’s bandwidth by 30 times for a whole 10 seconds!
Previously Cosmos DB lacked an out-of-the-box solution to handle such a huge spike. You had to:
- Either pay much more reserving more RUs,
- Or reinvent the wheel, complicating the system.
The Burst Capacity feature significantly reduces the probability of 429 errors, which means a better user experience for the end user. There is also a massive potential for optimizing costs if your database usage pattern contains spikes.
