[salmo]

I’m always more curious about the operational story, but new projects tend to focus on the low-level implementation.

I love Redis, but managing HA is a pain and requires a good bit of engineering on its own. I think this is how RedisLabs stays in business.

This seems to separate backend and front end, maybe so you could use a more appropriate storage for your use case?

But what would a production-ready deployment look like? How would you handle failover for patching or… failure?

Adding a front end can sometimes double the problem needing to have 1 failure setup for it and 1 for the backend. If I were to use the slab storage (looks really ideal for most of our workloads), how would that work?

Too much to answer here, but stuff I’d like to see as it matures. It’s the unsexy stuff, I know. Way more fun to get into the bits.

[thinkingfish]

Hopefully we can open source our deployment "generator" sometime soon. It's not gonna work in AWS (Twitter isn't a cloud first company) but you will get the basic idea.

Yes, swappable storage backend is a big driver of the design. Segcache for TTL-centric workloads, maybe some simple allocator-backed data structures for many popular Redis features, tiered storage for large time series... these were all internally discussed and sketched out to various extent.

Failure handling is very, very context dependent, both in terms of what the product does (which drives the ROI analyses) and where it runs (which determines ways things could fail). Still figuring out how to talk about fishing not the fish. Will give this more thoughts.

[salmo]

Thanks!

My dream world is to run the “same thing” in a public cloud, datacenter, and (limited resource) remote facility.

The latter wouldn’t need to be failure tolerant, just quickly recoverable as a service (not necessarily the data).

If I could provide 1 app usage pattern and 1-3 operational patterns that would solve so much.

This is hard for every data service, partly because of technical debt/entrenchment and data has gravity. But cache is the most flexible.

The joys of having a portfolio of 1000s of apps ranging from COBOL to “cloud native.”

Not a demand, just sharing the “needs” of my big traditional company for perspective. I feel that often times IT as an enabler vs IT as the product gets lost in the shuffle.

And so much assumes more Human Resources can be dedicated than a company that sees IT as overhead can dedicate.

All that said, constraints + scale can be a fun problem to solve. Making “right” easiest is always better than rules.