Update 2025-01-30-Scaling-Rate-Limits.md (#1833)

Fix miscalculated hourly volume.

content/en/post/2025-01-30-Scaling-Rate-Limits.md

@@ -8,7 +8,7 @@ display_default_footer: true
 display_newsletter_embed: false
 ---
 
-Let's Encrypt protects a vast portion of the Web by providing TLS certificates to over [550 million websites](https://letsencrypt.org/stats/)—a figure that has grown by 42% in the last year alone. We currently issue over 64,000 certificates per hour. To manage this immense traffic and maintain responsiveness under high demand, our infrastructure relies on [rate limiting](https://letsencrypt.org/docs/rate-limits/). In 2015, we introduced our first rate limiting system, built on MariaDB. It evolved alongside our rapidly growing service but eventually revealed its limits: straining database servers, forcing long reset times on subscribers, and slowing down every request.
+Let's Encrypt protects a vast portion of the Web by providing TLS certificates to over [550 million websites](https://letsencrypt.org/stats/)—a figure that has grown by 42% in the last year alone. We currently issue over 340,000 certificates per hour. To manage this immense traffic and maintain responsiveness under high demand, our infrastructure relies on [rate limiting](https://letsencrypt.org/docs/rate-limits/). In 2015, we introduced our first rate limiting system, built on MariaDB. It evolved alongside our rapidly growing service but eventually revealed its limits: straining database servers, forcing long reset times on subscribers, and slowing down every request.
 
 We needed a solution built for the future—one that could scale with demand, reduce the load on MariaDB, and adapt to real-world subscriber request patterns. The result was a new rate limiting system powered by Redis and a proven virtual scheduling algorithm from the mid-90s. Efficient and scalable, and capable of handling over a billion active certificates.
 
@@ -116,4 +116,4 @@ Before deploying the limits to track zombie clients, we maintained just over 12.
 
 Scaling our rate limits to keep pace with the growth of the Web is a huge achievement, but there's still more to do. In the near term, many of our other ACME endpoints rely on load balancers to enforce per-IP limits, which works but gives us little control over the feedback provided to subscribers. We're looking to deploy this new infrastructure across those endpoints as well. Looking further ahead, we're exploring how we might redefine our rate limits now that we're no longer constrained by a system that simply counts events between two points in time.
 
-By adopting Redis and GCRA, we've built a flexible, efficient rate limit system that promotes fair usage and enables our infrastructure to handle ever-growing demand. We'll keep adapting to the ever-evolving Web while honoring our primary goal: giving people the certificates they need, for free, in the most user-friendly way we can.
+By adopting Redis and GCRA, we've built a flexible, efficient rate limit system that promotes fair usage and enables our infrastructure to handle ever-growing demand. We'll keep adapting to the ever-evolving Web while honoring our primary goal: giving people the certificates they need, for free, in the most user-friendly way we can.