Using redfly

(1) An application is much more than a collection of complex SQL queries — although that is the unfortunate reality for most applications today.

The most important part of an application is the scaffolding - the login page, home page, menu items, etc. — everything that takes the user to where she wants to go. Rendering this can get painfully slow because it has devolved into a complex SQL query behind the scenes, which evaluates what areas the user can access. This SQL query's performance worsens over time as users and features are added.

No matter how complex your security logic is, it is very easy to evaluate it when everything you need is stored in the cache. The performance and scalability benefits of using the cache instead of the database cannot be understated.

This is why we cache that data and evaluate all of that on the cache for our management portal: https://transparent.azurewebsites.net

When all the pages in your application run at hyper-speed off the cache except the few pages that run complex SQL queries or reports, your database has that much more capacity to serve the few pages that do hit it. Users are much more understanding that requesting something that ought to take some time does take time — but everything else is super-fast.

(2) Chances are that you already use caching the good old way. In that case, you can use redfly to keep your cache up to date OR expire the cache when the data changes in the database.

"Database Change Notifications via Redis. Sometimes I just want to be notified that something changed - I don't need the updated data."

(3) We have had great success in running applications off cached objects rather than SQL queries.

(4) The ability to filter rows by one or more columns, or do simple JOINs across tables is possible with redfly.

(5) It is the simple queries which need protection behind the cache because most developers already know to protect the complex queries behind Redis.