umbrella-corp-boilerplate VS aperture

Hey, we have a system like that at my company. Microservices are self contained and responsible for exposing their interface via SDKs created with a tRPC like library. Jump to definition works across the entire monorepo like a charm. Could you take a look and give me any feedback? https://github.com/rectech-holdings/umbrella-corp-boilerplat...

Anyone interested in load shedding and graceful degradation with request prioritization should check out the Aperture OSS project.

https://github.com/fluxninja/aperture

I agree that queues can problem especially when misconfigured. But some amount of queuing is necessary, to absorb short spikes in demand vs capacity. Also, queues can be helpful to re-order requests based on criticality which won't be possible with zero queue size - in which case we have to immediately drop a request or admit it without considering it's priority.

I think it is beneficial to re-think how we tune queues. Instead of setting a queue size, we should be tuning the max permissible latency in the queue which is what a request timeout actually is. That way, you stay within the acceptable response time SLA while keeping only the serve-able requests in the queue.

Aperture, an open-source load management platform took this approach. Each request specifies a timeout for which it is willing to stay in the queue. And weighted fair queuing scheduler then allocates the capacity (a request quota or max number of in-flight request) across requests based on the priority and tokens (request heaviness) of each request.

Read more about the WFQ scheduler in Aperture: https://docs.fluxninja.com/concepts/scheduler

Link to Aperture's GitHub: https://github.com/fluxninja/aperture

Would love to hear your thoughts on our approach!

For those keen to dive deeper, I highly recommend exploring both the Twitter Space and Aperture: [Twitter Spaces]: https://twitter.com/kelseyhightower/status/1689355284802629633?s=20 [GitHub repo]: https://github.com/fluxninja/aperture

Very interesting blog post! Our team has been working intensively in this area for the last couple of years - flow control, load shedding, controllability (PID control), and so on.

We have open-sourced our work at - https://github.com/fluxninja/aperture

We would love feedback from folks reading this blog post!

Disclaimer: I am one of the co-authors of the Aperture project. There are several interesting ideas we have built into this project and I will be happy to dive into the technical details as well.

It's a blog on an open-source project that precisely tells you how to implement adaptive rate limiting.

Just click around a bit:

- https://github.com/fluxninja/aperture

- https://docs.fluxninja.com/use-cases/adaptive-service-protec...

Note: I am one of the authors' of this project.

At the time of writing, the first sample image on that page is this:

https://coderabbit.ai/assets/section-1-f9a48066.png

which recommends adding a "maxIterations" counter to the "for len(executedComponents) ..." loop here:

https://github.com/fluxninja/aperture/blob/26e00ea818c7c28da...

HOWEVER

- the review has failed to notice the logic using "numExecutedBefore" (around line 377) that already prevents the specific bug it is suggesting a fix for

- the suggested change decrements "maxIterations" inside the "for ... range circuit.components {" loop which means it isn't counting iterations, it's counting components

This kind of suggestion is particularly nasty because it's unlikely that the test suite populates enough components to hit "maxIterations" - so an inattentive reader could accept it, get a green build, and then deploy a production bug!

The need an adaptive protection system like Aperture[0] to mitigate overloads.

[0]: https://github.com/fluxninja/aperture

It’s customized to our policy spec. But you can learn from this and adapt it to your spec.

https://github.com/fluxninja/aperture/blob/main/scripts/json...