If Latency is Important, You Should Think Twice

Real time

If Latency is Important, You Should Think Twice

September 02, 2020

Redis recently announced a US$100M round of funding; a positive sign for the industry, especially in the current challenging environment.

In the article, co-founder and CTO Yiftach Shoolman states ambitiously that “If latency is important, you should think twice before you use a database other than Redis”. Always ready for a challenge, we did think twice, and share those thoughts here.

Low latency processing is a huge market – probably in the billions of dollars, but latency alone is not the “be all and end all”. Reacting really quickly counts for little if you are not taking the right decisions and reliably storing state so you don’t take the same decision twice. With enterprise applications you also get enterprise levels of complexity, which has led people to re-discover the benefits of SQL.

While the caching use case is pretty much standardized, different in-memory platforms take different approaches to supporting high volumes of transactions, leading to different products with varying capabilities and divergent architectures. Some use eventual consistency, some are single threaded. As a consequence, we do not believe there is a single, optimal product in this space, that can meet every possible low latency need.

What we are seeing is that vendors whose products lack ACID transactions and SQL are trying to retrofit them, but this is hard to do on a legacy code base without breaking existing APIs or negatively impacting performance. Using SQL to perform complex ACID transactions (Gartner calls this Augmented Transactions) at high volumes and low latency is what Volt Active Data was designed to do from the very start.

From a business perspective, we understand the seductive TCO appeal of a single database, but that era ended around 2005. We now live in a world where different databases for different use cases will be the norm, and an optimum strategy requires a tradeoff between having too many diverse platforms versus trying to use one platform for too many diverse use cases. Any platform that tries to handle “every” use case runs the risk of developing the same feature bloat, inflated costs and technical debt that led legacy RDBMS customers to flee in droves to less complicated and more affordable alternatives.

We’re happy to see the industry move forward, but it would be naive to think there is a single “real-time database for practically every everything that you need”. When evaluating a technology, you need to ensure it aligns with the use case in question.

For Volt Active Data, that means applications that are attempting to influence ongoing events, at a scale of half a million or more ACID transactions per second and within millisecond latencies.

  • 184/A, Newman, Main Street Victor
  • info@examplehigh.com
  • 889 787 685 6