From 42d042a988fb9f2d9054a954abdf59be44516a60 Mon Sep 17 00:00:00 2001 From: dd di cesare Date: Thu, 2 Nov 2023 18:32:48 +0100 Subject: [PATCH] [wip][rfc] Reference level explanation --- rfcs/0000-limitador-multithread-inmemory.md | 28 +++++++++++++++------ 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/rfcs/0000-limitador-multithread-inmemory.md b/rfcs/0000-limitador-multithread-inmemory.md index bbf1d3e..06b22f2 100644 --- a/rfcs/0000-limitador-multithread-inmemory.md +++ b/rfcs/0000-limitador-multithread-inmemory.md @@ -130,14 +130,28 @@ These scenarios will be explained in detail in the [Reference-level explanation] # Reference-level explanation [reference-level-explanation]: #reference-level-explanation -This is the technical portion of the RFC. Explain the design in sufficient detail that: - -- Its interaction with other features is clear. -- It is reasonably clear how the feature would be implemented. -- How error would be reported to the users. -- Corner cases are dissected by example. +This guide is going to be focused on the _InMemory_ storage option from Limitador, but the same approach could be applied to other storage options. +We will be using as reference a simplified version of the method signature `check_and_update` from the `Storage impl` +block [from the current Limitador crate](https://github.com/Kuadrant/limitador/blob/main/limitador/src/storage/mod.rs#L126-L134) + +```rust +pub fn check_and_update( + &self, + counters: &mut Vec, + delta: i64, + ) -> Result { + self.counters + .check_and_update(counters, delta) + } +``` -The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. +In brief, the `check_and_update` method is called by the `Limitador` service when a request is received. It receives a list of +`Counter` objects, which represent the limits that the request is trying to access, and a `delta` value, which represents +the amount of requests that the service is trying to authorize. It will iterate over the list of `Counter` objects and +will check if the request can be authorized or not. If the request can be authorized, the `Counter` object will be updated +with the new value. If the request cannot be authorized, the `Counter` object will not be updated and the method will +return an `Authorization` object with the `Authorization::Limited` value, otherwise the method will return an +`Authorization` object with the `Authorization::Ok` value. # Drawbacks [drawbacks]: #drawbacks