3 ms·
Yeah but this doesn't work with something like microservices, or even Kubernetes based deployments, right? It might take you 3, 40, or a 100 tries for the same
by sk0g 7y ago
Yeah but this doesn't work with something like microservices, or even Kubernetes based deployments, right?
It might take you 3, 40, or a 100 tries for the same request till you hit a node that has your data cached. It could work with extremely high req/seconds, though in an unpredictable way.
- heavenlyblue 7y agoTo be fair, what does it take you to write a simple caching microservice based on protobuf or similar?
- sk0g 7y agoA lot more knowledge in the relevant space that I have. I could spend a week or two learning necessary information, analysing our use cases and then implementing it finally (which I would never get the time to, from a business perspective). Or I could use an off the shelf product that is probably better than whatever I could come up with, given, even, unrealistic amounts of time to perfect it. I could come up with something more suited to our use case only, but the moment the use case changes, I'd wonder why I didn't just go with Redis. I haven't actually looked into a DIY method though. I just know I want something like Redis for our user table, because it's hit a lot, and the traffic tends to be repetitive.
- heavenlyblue 7y ago>> A lot more knowledge in the relevant space that I have. Relevant to what? You've already got a microservice mesh, which means you've also got a microservice architecture that's supposed to handle all of the RPCs. Adding a layer of Redis on top is probably going to introduce more entities into the system and make it less homogenous.