-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redis server-assisted client side caching #14417
Comments
This sounds interesting. Definitely needs a design proposal. cc @envoyproxy/redis-dev |
Hello! I have been working on it for sereveral days. |
Hey @mattklein123 Wanted to check in and understand what the process usually looks like for new Envoy feature development. Has there ever been a sponsorship model used successfully? We'd be interested in contributing, but do not necessarily have Envoy expertise, so if there are Envoy developers who are lacking funding and interested, there may be an opportunity to collaborate. Thanks again, |
We don't have anything formal here, but I can probably find someone for you to contract with. Can you reach out to me over email (available on my website) to discuss details? |
I just wanted to check in and see if anyone is actively working on this or has thought about the general design. @ronakts and I would love to collaborate if there is ongoing work, otherwise, we're going to ramp up on this area of the code base and propose a design and work on an implementation. |
Feature Request: Redis server-assisted client side caching
Envoy is an incredible tool that we've found critical for proxying redis connections, with the release of Redis 6, there seems to be an opportunity to take Envoy's redis capabilities to the next level by acting as an even faster local cache to Redis through the support of server-assisted client caching. Adding this capability to Envoy will make it simple to increase cache locality for many applications with a small, hot set of data, making it straightforward to build efficient sharded applications by handling asynchronous cache invalidation.
There would need to be substantial thought in terms of the memory profile, since it will shift Envoy from being a lighterweight proxy to also a relatively "thick" proxy-cache. I could imagine users tending to run a dedicated Envoy with a larger memory allocation separate from the lighterweight proxy variant for the purposes of isolation.
Regardless -- I really appreciate the work that Lyft, Matt Klein and all other contributors have put into this project, thank you all for the hard work 🙌
The text was updated successfully, but these errors were encountered: