Why you should consider a Databaseless architecture

Raja has been an engineer, developer advocate and a tech writer with nearly two decades in the software industry. He’s now transitioned into growth marketing and writes mostly about databases and big data. One of the most popular approaches to breaking down complex problems relies on first principles, which forces you to think for yourself and not just follow the tradition but question everything.

There is an emerging first principle in software development: databaseless (DBLess) architecture, which provides a new approach to data pipeline and backend architecture. The terms ‘serverless’, ‘stateless’ and ‘NoSQL’ attempt to provide more options for software architects and developers.

In essence, first principles thinking means that unless you’re looking at a law of nature, such as the laws of gravity, every system or concept is manufactured and can have inefficiencies. To add to that, the passage of time or technological innovation could have proven the concept obsolete, meaning you should regularly question the traditional system or ideas and see if you can build something better.

Finding those inefficiencies requires a systematic and scientific approach that breaks them into smaller pieces to get to the fundamental truths. Then, if the passage of time or invention of new technology has made any of these pieces obsolete, you have a chance to build a more unique and better system.

With DBLess architecture, you can get rid of your primary database, hence the name. Instead, you rely on the formerly secondary/cache database as the new primary data store for your entire app or select services an app depends on.

How using first principles helped in the emergence of electric vehicles

We all know that a battery is a critical component of a car. But while a petrol car does have a battery, it’s not used for running the vehicle. It uses batteries for starting the engine, air conditioning, audio systems, lights, sensors, locks, and so on, but not for running the car. Instead, it relies on an internal combustion engine (ICE).

It turns out ICE cars are highly inefficient. Only 16% to 25% of the power that’s generated actually makes it into the wheels. On the other hand, electric vehicles provide about 90% power to the wheels! Electric vehicles also have significant advantages when it comes to the environment, repair costs, and so on. If you are looking at this from a first principles perspective, you’d question how to make a cost-effective battery to power the entire operations of a vehicle. When Elon Musk of Tesla did that, he came up with the first mass-produced, mainstream electric vehicle.

Electric vehicles, in essence, have removed an inefficiency by simply getting rid of the complex ICE and replacing it with a cost-effective battery which could provide the necessary energy required to spin the wheels directly. It’s clear then how first principles thinking leads to identifying inefficiencies and creating a newer, better system. So how can we apply the same first principles approach to the world of software development?

Traditional vs Databaseless: A comparison

Let’s look at traditional software architecture first. In a traditional architecture, you have a primary database and a secondary database or cache. The primary database is used to store all the data and support CRUD operation, while the caching database is used for caching, session storage, rate-limiting, and many other things.

Here the comparison with petrol cars becomes clearer. Much like petrol cars carry a battery to power numerous things except for moving the vehicle; traditional architectures use technologies like Redis for everything except as the primary database.

Applying the rules of first principles: why not do what Tesla did for vehicles, get rid of the slow and inefficient primary database, and directly use the cache database as the primary database? In other words a “DBLess” architecture. With this approach, you get caching, rate-limiting, session storage and all the primary data for CRUD in a single database.

What makes this possible is that Redis has evolved from a cache database to a multi-model, primary database with enriched capabilities that go beyond its core data structures. Redis can be deployed as a document store, full-text search engine, a graph database, a time-series database, and more––as a foundation for powerful real-time applications and services across a wide range of industries and use cases.

This approach allows organisations to use Redis or similar caching databases as their primary database and reduce or eliminate their use of databases designed (literally) in a different century. Some have even built their entire start-up on this architecture and reaped the rewards.

Moving into the future

If you are building a new system or a new feature, it’s straightforward to start using this architecture—or at least try it out via a proof-of-concept and see if it works for you. For those who already have a primary database, there’s also the option of a hybrid approach. In this scenario, developers can continue using their traditional architecture and migrate parts of their product into the newer architecture, such as elements of their technology stack where they’re already relying heavily on newer technologies. Slowly but surely, this can make it easy to migrate all the features one by one until they’re completely migrated over.

Becoming a first principles thinker

We all need to remind ourselves to be first principles thinkers. Just because something is traditionally used, it doesn’t mean it’s perfect and that we should blindly follow it. Instead, question traditional assumptions, critically examine them and try alternatives. And when we do, we might create something valuable that anyone can benefit from.

DBLess architecture provides an alternative to traditional thinking. Instead of wondering if it’ll work or not, try a proof-of-concept. It might just surprise you!