The author writes about how he used this system to solve a case of a slow query. However, this is really sort of the wrong query to illustrate why we built this. It's more of a "oh hey look since we already have this data super fast in this other system, lets just use it."
What the system does is allow us to arbitrarily summarize at whatever granularity we want, any second, to any second.
For example we can ask it to summarize January 4th at 11:22:02 to March 1st at 16:22:09, and so however many writes happened during that time at any second are tallied up very quick, because of the way the data is stored. So even though lets say during this 3 month~ period you have 10,000,000 writes for one user some that say "add 3" or "remove 4", you will only query at a second granularity around the edges, and the middle you will query whole day, or month buckets.
Another way of explaining the point of this system is that it allows us to really quickly (well under 1ms) summarize any data in the past N days (N usually equals 120) from any start to any stop point we want, using any granularity we want, and we can do it concurrently and generate this for 1000 users at a time and it all can happen in 30-50ms. Considering that the underlying data is recorded at second granularity, and can be retrieved at that granularity and automatically expired when this granularity is not needed, redis is the right tool for the job here. To accomplish this in pure sql you would have to log all writes you make to the table, and query this change logging table in a similar way. So not only would this add a lot of overhead to the database as a whole, but a lot of churn to remove the lower granularity when its not needed.
We will be polishing the system more over time, and more blog posts will come out when we release some of the client code ;)