From 7a4cb7427f821b6998d2dafdb257130ea6dfa546 Mon Sep 17 00:00:00 2001 From: Grzegorz Bizon <grzegorz@gitlab.com> Date: Fri, 16 Sep 2022 07:33:07 +0000 Subject: [PATCH] Copy-edit changes to rate limiting blueprint --- doc/architecture/blueprints/rate_limiting/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/architecture/blueprints/rate_limiting/index.md b/doc/architecture/blueprints/rate_limiting/index.md index 9631be7e6a417..16f06aaaf46d1 100644 --- a/doc/architecture/blueprints/rate_limiting/index.md +++ b/doc/architecture/blueprints/rate_limiting/index.md @@ -216,15 +216,15 @@ We should, however, avoid the possible negative-feedback-loop, that will put additional strain on the Rails application when there is a sudden increase in usage happening. This might be a big customer starting a new automation that traverses our API or a Denial of Service attack. In such cases, the additional -traffic will reach GitLab Rails and subsequently also other sattelite service. -Then the sattelite services may need to consult Rails again to obtain new +traffic will reach GitLab Rails and subsequently also other satellite services. +Then the satellite services may need to consult Rails again to obtain new instructions / policies around rate limiting the increased traffic. This can put additional strain on Rails application and eventually degrade performance even more. In order to avoid this problem, we should extract the API endpoints to separate service (see the section below) if the request rate to those endpoints depends on the volume of incoming traffic. Alternatively we can keep those endpoints in Rails if the increased traffic will not translate into -increase of requests rate or increas in resources consumption on these API +increase of requests rate or increase in resources consumption on these API endpoints on the Rails side. #### Decoupled Limits Service @@ -235,7 +235,7 @@ required, and exposing API, out of Rails. It is impossible to make a decision about extracting such a decoupled limits service yet, because we will need to ship more proof-of-concept work, and -concrete iterations to nform us better about when and how we should do that. We +concrete iterations to inform us better about when and how we should do that. We will depend on the Evolution Architecture practice to guide us towards either extracting Decoupled Limits Service or not doing that at all. -- GitLab