Announcing Smart Invalidation
Today we are excited to announce Smart Invalidation for automatic cache
invalidation on data changes. PolyScale continuously processes and analyses all
SQL queries that pass through the platform. With Smart Invalidation, when SQL
updates are detected (Data Manipulation Language (DML) -
DELETE), PolyScale automatically invalidates the associated data from the
Caching is a tradeoff between performance and data freshness and with the release of Smart Invalidation, we have taken another significant step towards reducing the impact of that tradeoff, whilst maintaining a no-code approach to caching.
Smart Invalidation is valuable anywhere where data freshness is critical, or where data is being updated regularly. The vast majority of use cases can be addressed using time-based invalidation (Time To Live - TTL) where values are set that are appropriate to the rate of change. For example, in an e-commerce use case, if product catalog entries individually change infrequently, their TTL’s could be set for long durations, with the tradeoff that an entry could be out of date for up to that period of time. Today PolyScale monitors and recommends the TTL-based values automatically, as without it, this process of continuous measuring and monitoring is complex and always changing.
With Smart Invalidation PolyScale users are now able to guarantee that the most current data is always served with no compromises being made around consistency.
We believe Smart Invalidation is useful to the majority of use cases however, working with customers we have seen several where Smart Invalidation is particularly beneficial:
For busy online booking environments, offering availability that is no longer valid can lead to a poor user experience i.e. a user attempts to make a booking that is now unavailable. With Smart Invalidation, when bookings are confirmed, they will no longer be available in the cache on the next query for the schedule.
Coupled Site & Admin Apps (WordPress, Drupal, Woocommerce, etc)
There are many platforms that couple both the website client interface and the administration interface into the same web application. Examples of these include WordPress, Drupal, Woocommerce, etc. In these environments, business stakeholders administer the sites using the built-in web-based tools. These tasks can include everything from adding new content e.g. writing a blog article in an e-commerce use case, adding or removing products. After making these changes, if the front-end application is cached, these changes will not be available to end users until the cache is refreshed i.e. the TTL has expired. This behavior can be confusing to users.
Previous solutions have required writing custom code or configuring plugins, or separating the admin and the websites database access to only serve the front end site from cache.
With Smart Invalidation, this is no longer the case. Admin changes are immediately visible to the site in real-time.
Scaling APIs is a common use case for PolyScale where any data-driven resource can be scaled effortlessly. API authentication (using a unique string key for example) is a common candidate for caching whereby each request is validated, usually against a database such as Redis or similar. In this case, being able to invalidate the cached keys on change (key rotation, resets, etc) automatically is critical, rather than having to wait for TTL expirations, or calling a global cache purge.
How Does It Work?
PolyScale evaluates each SQL query in real-time and when it detects a DML query i.e. a SQL INSERT, UPDATE or DELETE, it extracts the associated tables for the query. Then, all data for the table(s) in question are purged from the cache, for every region globally. The invalidation takes place first at the Point of Presence where the DML query originated and is then propagated to all other PoPs globally. Smart Invalidation provides global eventual consistency that resolves in a few tens of milliseconds.
Smart Invalidation provides automated consistency management whilst maintaining our no-code approach to caching
Ben HaganPolyScale Founder
Extracting tables as the basis for the invalidation is effective; however, next will be optimizing Smart Invalidation for more fine-grained control. Rather than invalidating all data for the tables that have been updated, only invalidate the specific data that has been affected. This is an ongoing efficiency optimization and the efficiency results are shown within the PolyScale Observability dashboard.
In addition, there are use cases where the update traffic is not visible to PolyScale i.e. updates are not flowing through the PolyScale platform. If that is the case, then the AI-driven TTL value will control the invalidation. We have a lot more to share here in the future regarding CDC streams for these types of use cases.
Smart Invalidation is now in Beta globally for all PolyScale users and enabled by default.
Ready to try PolyScale.ai? Sign up for a free account here (no credit card required). Or try out PolyScale without bringing your own database with our live interactive demo playground.
Read the Quick Start Guide to understand how easily PolyScale can be integrated without code and without deploying servers.