Definitely Going To Implement A Fast/Slow Persistence Model

One of the things that I want to implement for Mabel is fast/slow data persistence. 

It works as follows:

• When data needs to be loaded, the first thing that's checked is a 'fast' persistent store like Redis. If the desired data isn't located in the fast store a slow store, like a MySQL database, is then checked.
• When data is saved, the data is first saved to the slow store. Then the old data in the fast store is replaced with the newer.

Why would I want to implement this? Well, slow is . . . slow. In the case of a MySQL database, you really don't want every single SELECT statement in production to execute against the database, especially since a large number of those statements return identical result sets. Might as well cache those identical result sets somewhere and take the load off the system.

If I were going to do a full implementation of a fast/slow system I would also put the slow system updates behind some sort of a queuing tech like RabbitMQ or something bespoke built on top of Redis. That's really only necessary when you're very very concerned about your slow store being overwhelmed by the number of writes it's being asked to do or the update to the slow store needs to trigger other back-end processes that you don't want handled synchronously (like sending emails).

At this point in time, that's not necessary so I'm not going to build it.

But yah never know. Maybe some day . . .