Perhaps simplified Redis example could work as a good base to learn C. Single threaded, memory only persistence, network communication service so no complex stuff like concurrency and file management. Though there's probably a lot more going on in there...
Perhaps "Redis for devops" is another book waiting to happen, or how to write Redis modules. By the way, Manning's book (from 2013) is freely available these days: https://redislabs.com/resources/ebook/
I think a redis book is good, but your docs and blog articles are already excellent. If you combined them into a single document (slightly updated or curated blog articles as chapters, with the second half of the book as reference section/appendix for redis.io commands) then your book is done. You could probably even just hire someone to handle this formatting.
The C book sounds really fantastic.
* (btw, antirez wrote redis.)
At the first glance it looks simple. Later if you use it, it can get a beast very fast. But after you get some more knowledge about this, you know how to deal with it.
What i really like is your approach you mentioned: "Over the last years i learned...". And the users of redis can feel this. More and more commands and tools are implemented in redis that makes handling of bigger envs way easier or tools to speed up your debugging sessions like WATCHDOG, SLOWLOG, latency based testing (as mentioned in the article).
Don't get me wrong. This article is not about blaming redis. I and we as a company, love redis. Thank you.
Understanding your problem and the tools as you mentioned deeply allow the great things, or just, keep fingers crossed and hope for the best.
A lot of problems can often be reduced in complexity by really understanding what you need vs. what you think you want or your user wants. The real challenge is translating what is wanted into what is needed (which is often hard to explain to clients).
Obviously I've benefited from your work on Redis, so if you'd like a hand converting the site over to Markdown or with the books (proofreading, technical editing) I'm happy to help. Let me know!
Redis pushes the limit of what can be accomplished using a single-threaded in memory data store. If your processing can be done by such a thing, Redis is probably the most efficient option available. (With, of course, persistence, replication, and so on for managing your data.)
But if you throw blocking operations or too much data at it, Redis is going to demonstrate the inherent limitations that come with being a single-threaded in memory data store.
How about adding something about this in the documentation, if you haven't already?
- Do use Redis for <X>
- Do NOT use Redis for <Y>Definitely. And on top of that, Redis is very easy to get started with, and as the article illustrates, you can plug along very smoothly until you suddenly find a mountain to climb. Shouldn't scare someone off, but one of the lessons is to understand what you're implementing and where the bottlenecks will eventually be - much easier said than done, in my experience, but something to aim for.
Certain things I understood over the years that made it better are, of course, improvements in the implementation, but especially things like LATENCY DOCTOR and MEMORY DOCTOR (this one only for versions >= 4.0), that is, most of the things a Redis operations expert can tell you, Redis can tell you directly... without any other help, just observing its internal behavior.
There is another aspect. For a long time I believed a Redis book was not really needed. Now I changed my mind, and I see no good enough Redis book out there, and I'm almost planning writing one... I was writing for a long time, incrementally, a C book, that is currently just an incomplete draft. I'm thinking about abandoning for now this project, and start with a Redis book.