It's fascinating seeing all the comments elsewhere anytime Waymo starts testing in another city along the lines of, "ah, but how will they handle X, Y, and Z here?? Checkmate, robots!" despite having already launched service in several other cities.
Granted, NYC is the biggest city in the US, so maybe that sort of reaction is more reasonable there than when people in Dallas or Boston do it.
NYC (at least the parts I've spent a bit of time in) is pretty grid like with fairly simple roads. The drivers are the hard part :)
I am excited to see them tackle Boston at some point because of how strange some of those roads are. The first time I had ever been I came to an intersection that was all one ways and there were like 7 entry/exit points. My GPS said turn left, but there were three paths I'd consider left. Thank god I was walking.
And I don't really pose much doubt because it seems like Waymo's rollout plan has been solid, but I'm just interested to see how well they tackle different cities.
The first few solutions are all fine for probably most cases. The dismissal of the fixed window solutions has no explanation behind why we don't want that.
> The first downside is a client could submit all his requests for a given second at the end of that second, and then submit all his requests for the next second at the start of that next second, which is not what we want.
I'm okay with that. My current company gives customers API limits per minute. Do you want to fill that up in ten seconds or across the full minute? Doesn't matter, we let you do it. I assume plenty of services acknowledge that this is fine for their use case too.
> We needed to use a transaction to do something that’s supposedly trivial for a given database product
What is the use of a transaction bad? It's not explained.
I've written quite a few Redis based rate limiters for services that get a good amount of traffic and I've never had an issue. I'm not writing APIs that get AWS or OpenAI levels of traffic, but most people aren't. Redis has never hiccuped on me with rate limits in a way that I've ever noticed. Plus the code was written within an hour or two each time, along with tests.
And then, as many of the other comments here have pointed out, this is from a rate limits as a service company, so that explains the empty attacks on Redis for this use case. Not to knock this product - it may be incredible for some serious rate limiting use cases, but most people using Redis for their rate limits don't have that.
I also wouldn't be surprised if having a hosted ElastiCache cluster in AWS is cheaper than their service while providing the same benefit for the majority of companies' scale, while also avoiding vendor lock in (because I can get Redis anywhere I turn). Hell, at a previous place I worked we also threw other unrelated cache data in the same ElastiCache cluster without thinking about it, because Redis is so convenient and powerful when it's appropriate.