What a cache integrated Data Access Layer looks like, and how it helps you simplify your business logic improving productivity

This article is written by our sponsor nautilus2k.com which is a new startup trying to help other startups building data-driven apps on the Microsoft .NET Core/ Azure tech stack.

This is part 3 of the previous articles:

When your B2B startup has no people, money or resources think out of the box to build your product

How this startup helps you build a scalable app with a minuscule team, on a shoestring budget

If you have read the previous two articles, you know that we talk about generating most of your data access layer. We also mentioned that the generated code is built on top of Entity Framework Core, and is integrated with caching which gives you extreme scalability & performance.

In this article, we will explain what this means & why it is a significant advancement over the norm.

Reading changes from databases

Many companies have built services which synchronize their relational database to their cache. They do this to achieve near real-time sync with their cache, so that their applications are able to show real-time activity. As an example, if your vehicle data is stored in SQL Server, and you can efficiently cache the data as it comes in, you can show vehicles moving around in Google Maps without creating massive load on your database.

The problem with this scheme is that:

• It is extremely hard to implement and to keep running 24x7 without issues.
• It is tightly customized to your database, so it can’t really be reused.
• Your database still needs to run at very high performance (bare metal or significant CPU capacity), to be able to keep your cache up to date.