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) - INSERT, UPDATE or
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
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
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
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
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.
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
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
Smart Invalidation is now in Beta globally for all PolyScale users and enabled
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.