Creating Scalable APIs with Azure Cache for Redis Enterprise

🆕 Update (April 2025): When this article was first published, I did the example using Azure Cache for Redis Enterprise. Today, the evolution of ACRE — Azure Managed Redis — is in public preview and soon to be GA'd. The example should work with AMR, but I will create a new repository and article soon.

In today's fast-paced digital world, building scalable APIs is crucial for ensuring your application can handle increasing loads and provide a seamless experience for users. One of the most effective ways to achieve this is by leveraging Azure Cache for Redis Enterprise. In this article, we will explore how to create scalable APIs using ACRE.

Background

If you have been in the technical field long enough like me, you are pretty familiar with relational databases. Relational databases were conceptualized in 1970 and brought to the commercial space in 1979 by Oracle. They were created to run in systems with limited resources, thus the applications were small with a small memory footprint. Push forward to 2000's and now SQL is crushing the commercial space. The problem was relational databases were not built to scale from the start. They were little by little adapting through time with the release of new hardware and new demands, but I don't think in the 70s they were thinking there would be a day we could store Petabytes of data. That's why No-SQL databases were created, to address the scalability challenges from the beginning.

Now, I'm not saying that you need to replace every relational database with Redis -- mmm maybe :) -- but what I'm saying is to start re-evaluating your architecture based on the use case. If you have a problem with scalability, speed, or complexity go ahead and check Redis out. There's a new E1 tier in Azure Cache for Redis Enterprise created as an entry point for dev purposes and it is very cost-effective. Also, if you are architecting a brand new app and know the app is going to be heavily used, you should start with Redis in mind.

The Scenario

Let's check out an actual real-world scenario.

You and your team built an application: React (UI)+ .NET(API) + Azure SQL(DB). It uses clean architecture so it is relatively easy to update things software side. Everything has been running fine but you start noticing performance problems. You tracked down the bottleneck and identified that is a database that can't keep up with demand. You are getting more reads than writes. You decide to implement the CQRS pattern to split reads and writes and offload the reads from the SQL Server. You start using Azure SQL Managed instance and create read-replicas but your application needs to do a read right after a write. The problem that you will encounter is in this article:

"Typical data propagation latency between the primary replica and read-only replicas varies in the range from tens of milliseconds to single-digit seconds."

Single-digit seconds may not sound bad for you, but some applications need to read right after a write and this means not seeing the data right away, hence creating a negative impact on the business.

The Solution

In this example, you can find a scalable API that uses, clean architecture, CQRS, Mediator Pattern, and DDD. We are using a serverless approach with Azure SQL trigger for functions to implement a scalable data ingest pattern from Azure SQL to Azure Cache for Redis Enterprise. Stay tuned to my next article where I show how to do these patterns with RDI.

Key Components

• Azure Cache for Redis Enterprise
• Azure Functions
• Azure SQL
• App Service

What is Azure Cache for Redis Enterprise?

Azure Cache for Redis Enterprise is a fully managed, in-memory caching solution designed for high performance and scalability in collaboration with Redis the company.

The service will efficiently handle millions of requests per second with sub-millisecond latency. Additionally, it offers the benefits of a managed service, including easy configuration, robust security, high availability, a powerful search engine, extended data types such as JSON, Time-series, Probabilistic, and more.

Architecture

Here's the architecture for both scenarios.

Considerations

1. Is important to mention that the Azure SQL trigger for functions has configuration options that you can use to help you scale. Here is the table with the information from the Microsoft site.

2. Pay attention the the tier you use for the app service. Not all of them will autoscale.

3. Check the performance document of ACRE. It will help you select the best tier when using basic caching. Feel free to reach out if you need help with sizing, especially if using advanced data types such as RediSearch as you need to consider data size, throughput, etc. to select the best tier for your use case.

4. If deploying the application in multiple regions, you should use a global load balancer for the apps and the Active Geo-Replication feature of ACRE, where you can deploy multiple clusters as part of a geo-replication group and stay in sync. This will give you a 5-nines SLA when combined with zone redundancy.

5. Try it out and test, test, test! Each use case is different and many factors can contribute to the stack not performing. I encourage you to test the stack before deploying it to production.

Conclusion

Azure Cache for Redis Enterprise is a real-time data platform, excellent for building scalable APIs with minimal overhead. By leveraging the capabilities of serverless computing with Azure Functions to implement the data-ingest or write-behind caching patterns, you can focus on developing high-quality APIs that can automatically scale to meet demand.

I want to hear from you! Reach out if you have any questions about the service. Feel free to explore, collaborate, and open any issues on the repository and start building your scalable APIs with ACRE today!