User Connectivity: Two Years in Production — Lessons Learned and New Patterns

Source: Dev.to

Introduction

This is a follow‑up to my previous post on User Connectivity: A Real‑time Web Solution for Online and Offline User Status. It has been almost two years since I first deployed my user connectivity solution to production. What started as an experiment has become a cornerstone of my architecture.

Recently, I encountered complex database deadlock issues caused by several API processes. After analyzing the problem, I recognized an opportunity to apply my event‑driven architecture. By separating out specific tasks and processing them asynchronously, I eliminated the deadlocks entirely.

The goal of the Event Distributor is simple: one central service that listens to Redis expiration events and nothing else.

Event Distributor Benefits

• Traceability – All events pass through a single point, making it easier to trace issues.
• Logging – Every received event is logged to an Azure Cosmos DB with its status.
• Scalability – Worker functions can scale independently based on queue depth.
• Reliability – A single, well‑monitored listener reduces the risk of missed events.

After two years of running this architecture, I have two critical observations for anyone implementing a similar solution with Azure services.

Critical Observations

1. Use Premium Plan for Redis Listeners

Why?
The Consumption plan has cold‑start delays and limited connection lifetimes. When the Function App is idle, it can go to sleep and miss events from Redis. With the Premium plan, your Function App is always on with long‑lived connections — no cold starts, no missed events. I have not seen a single lost event since moving to Premium.

You may ask: how did the original user connectivity solution work on the Consumption plan?
It managed, but the risk of missed events was higher.

2. Azure Managed Redis Limitation

There is a significant limitation: Azure Managed Redis servers cannot be fully configured to send expiration events reliably. When the underlying servers restart or cycle, they lose their configuration and stop sending expiration events.

I have reported this issue to Microsoft. They confirmed it is on their backlog, but as of today, there is no solution. If your architecture depends on Redis key expiration events, be aware of this limitation before migrating to Azure Managed Redis.

Takeaways

• Use the Premium plan for Redis listeners to avoid cold starts and missed events.
• Be cautious with Azure Managed Redis if you rely on expiration events, as the configuration may be lost on server restarts.

I hope this helps others take advantage of this architecture.