Skip to content

Commit 3d16710

Browse files
committed
[rfc] Fine tuning UX option moved to future possibilities
* Bonus: fixing typos
1 parent b426e96 commit 3d16710

1 file changed

Lines changed: 19 additions & 15 deletions

File tree

rfcs/0000-limitador-multithread-inmemory.md

Lines changed: 19 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -61,15 +61,9 @@ In this example, we are configuring the service to use the _InMemory_ storage an
6161
limitador-server --mode=throughput memory
6262
```
6363

64-
In a future iteration, we might be able to provide a richer interface that allows the user to configure the service
65-
in a balanced and/or more granular way.
64+
In this other example, we are configuring the service to use the _InMemory_ storage and to use the _Accuracy_ mode.
6665
```bash
67-
limitador-server --mode=balanced --accuracy=0.1 --throughput=0.9 memory
68-
```
69-
70-
or simply
71-
```bash
72-
limitador-server --accuracy=0.1 --throughput=0.9 memory
66+
limitador-server --mode=accuracy memory
7367
```
7468

7569
## Implications
@@ -132,12 +126,12 @@ twice in a row, for example, when trying to revert the _overshoot_ from the prev
132126
Enhancing the Limitador service to process requests in parallel and being capable of operating in the previously described
133127
modes, entails considering various implications.
134128

135-
Firstly, ensuring consistency in storing counter values across multiple threads is paramount to maintinging the integrity
129+
Firstly, ensuring consistency in storing counter values across multiple threads is paramount to maintaining the integrity
136130
of rate limiting operations. This involves implementing robust concurrency control mechanisms to prevent race conditions
137131
and data corruption when accessing and updating shared counter data.
138132

139133
Additionally, choosing the data structure that will store the counter values must prioritize efficiency and thread safety
140-
to handle concurrect access effectively.
134+
to handle concurrent access effectively.
141135

142136
Finally, considering that initially we will implement the setup of the mode at the service initialization time, balancing
143137
the need for strict adherence to defined limits with the desire to maximize throughput presents a trade-off that we could
@@ -180,17 +174,17 @@ described in the [Guide-level explanation](#guide-level-explanation) section.
180174

181175
#### Accuracy mode
182176

183-
* In Accuracy mode, we need to strictly adhere to the defined limits by denying requests that exeed the limits for each
177+
* In Accuracy mode, we need to strictly adhere to the defined limits by denying requests that exceed the limits for each
184178
Counter Object.
185-
* Check and update Counter values atomically to maintin consistency and prevent race conditions.
179+
* Check and update Counter values atomically to maintain consistency and prevent race conditions.
186180
* Enforce rate limits accurately by comparing the number of hits within the sliding window to the defined limit.
187181

188182
#### Throughput mode
189183

190184
* In Throughput mode, we need to prioritize maximizing the number of requests that can be processed concurrently over
191185
strict adherence to defined limits.
192-
* Allowing request to proceed even if they temproarly exceed the defined limits, favouring higher request rates.
193-
* We should use appropriate concurrency mechanisms and CAS oeprations to handle request efficiently while maintaining
186+
* Allowing request to proceed even if they temporarily exceed the defined limits, favouring higher request rates.
187+
* We should use appropriate concurrency mechanisms and CAS operations to handle requests efficiently while maintaining
194188
consistency in the counter data. We might not need to use locks, but we need to be careful with the CAS operations nonetheless.
195189

196190

@@ -232,6 +226,16 @@ that the service operates correctly and efficiently.
232226
- **Dynamic mode selection**: We could introduce a mechanism to dynamically switch between _Accuracy_ and _Throughput_
233227
modes based on the current load and performance characteristics of the service.
234228
- **Fine-grained configuration**: We could provide more granular configuration options to allow users to fine-tune the
235-
behaviour of the multi-threaded Limitador service based on their specific requirements.
229+
behaviour of the multi-threaded Limitador service based on their specific requirements. As shown below, we might be able
230+
to provide a richer interface that allows the user to configure the service in a balanced and/or more granular way.
231+
```bash
232+
limitador-server --mode=balanced --accuracy=0.1 --throughput=0.9 memory
233+
```
234+
235+
or simply
236+
```bash
237+
limitador-server --accuracy=0.1 --throughput=0.9 memory
238+
```
239+
236240
- **Performance optimizations**: We could explore various performance optimizations such as caching, pre-fetching, and
237241
load balancing to further improve the throughput and efficiency of the multi-threaded Limitador service.

0 commit comments

Comments
 (0)