Agreed. This quote seems relevant: "Everything should be made as simple as possible, but not simpler."
The article talks about using rate limiting using Redis and dropping it in favor of handling it on each server node and assuming uniform distribution of requests. Doing that is a trade-off of precision rate-limiting for a simpler architecture.
That may be a good trade-off, but only if you can get away with it. If they were required to have more precise rate-limiting then the simpler architecture would not have been possible.
In my own work, I used Memcached instead of Redis for rate limiting data. The applications were coded to fall back to the per-node rate limiting if Memcached weren't reachable. Memcached may have been another dependency, but it was one of the less troublesome dependencies. I never experienced a problem with it in production. The fallback behavior meant that we didn't even need Memcached in a dev environment.
I guess my point is this: Not all dependencies are as troublesome as others.
The article talks about using rate limiting using Redis and dropping it in favor of handling it on each server node and assuming uniform distribution of requests. Doing that is a trade-off of precision rate-limiting for a simpler architecture.
That may be a good trade-off, but only if you can get away with it. If they were required to have more precise rate-limiting then the simpler architecture would not have been possible.
In my own work, I used Memcached instead of Redis for rate limiting data. The applications were coded to fall back to the per-node rate limiting if Memcached weren't reachable. Memcached may have been another dependency, but it was one of the less troublesome dependencies. I never experienced a problem with it in production. The fallback behavior meant that we didn't even need Memcached in a dev environment.
I guess my point is this: Not all dependencies are as troublesome as others.