Backblaze Rate Limiting Policy for Consistent Performance

A decorative image showing clouds connected by digital lines.

Editor’s Note

We have updated this blog post to reflect changes to our policy.

Highways have guardrails for a reason. They help ensure that large volumes of traffic can reach their destinations quickly and safely. And they help support order and predictability in systems where some folks might otherwise be inclined to go off-road on occasion even if doing so could disrupt other vehicles, harm neighboring land, and whatnot.

Backblaze is now applying such fundamental highway engineering thinking to the B2 Cloud Storage platform, introducing a rate-limiting guardrail policy designed to better serve customer needs well into the future while better safeguarding the stability and quality of our service from adverse impact of one customer or set of customers creating a traffic pile-up for everyone else. 

This policy is designed to address system abuse. Based on our analysis of customer usage patterns, we do not expect any impact to customers legitimately using the service–just smooth sailing, or open road if we stick to the highway analogy.

In the event of an unexpected API usage spike that appears to be abusing the system, a customer will temporarily receive a 503 status code when using our S3 compatible API, or a 429 status code when using our Backblaze B2 native API. These status codes are similar to what you’ve seen from other global cloud object storage providers including Amazon Web Services S3 and Microsoft Azure.

If you run into any issues of repeatedly 503 or 429 status codes, please contact us and we’ll dig into the details with you.

Click down details:

  • All Backblaze B2 customers will be under the governance of the policy after it is rolled out across the platform. Backblaze Computer Backup usage is not within the scope of this policy.
  • We originally introduced a rate limiting policy with more stringent call request limits for customers storing 10TB and below; we have subsequently rolled back those limits and changed our system approach to focus on safeguarding the system.
  • Managing a storage platform for performance and security at exabytes scale is a dynamic activity, so we’ll likely continue to refine our approach and introduce more improvements over time. We will announce significant changes here on the blog.

You can visit our API documentation for more information.

About Jeremy Milk

Jeremy Milk is a storybuilder who heads the Backblaze Product Marketing team. He's spent more than two decades honing his craft in product and consumer goods marketing leadership roles at companies including Intuit, WePay (acquired by JPMorgan Chase), and The Clorox Company. Outside the office, he can often be found near a soccer field, on a running trail, or fueling on coffee and tacos. Follow him on LinkedIn or Twitter.