Do you use live connections instead of polling?

When your application needs real-time data updates, you have several options: polling, webhooks, or live connections. Polling - where clients repeatedly request data at intervals - is often the first solution developers reach for, but it's usually the worst choice for real-time scenarios.

Studies show that 98.5% of polling requests are wasted - they return no new data. This "Polling Madness" wastes server resources, increases costs, and still doesn't provide true real-time updates.

Why polling is problematic

Imagine 10,000 users polling your API every 5 seconds. That's 10,000 requests per second your server must handle - even when there's nothing new to report. With live connections, you'd only send data when something actually changes.

Polling problems:

• Wastes server resources (98.5% of requests return nothing new)
• Creates artificial latency (users wait for the next poll interval)
• Scales poorly (more users = exponentially more requests)
• Drains mobile device batteries
• Increases infrastructure costs

Live connections benefits:

• Push data only when changes occur
• True real-time updates (sub-second latency)
• Scales efficiently
• Better battery life for mobile apps
• Lower infrastructure costs

Choosing the right technology

When to use SignalR

SignalR is the recommended choice for .NET applications. It automatically selects the best transport (WebSockets, SSE, or Long Polling) and provides:

• Automatic reconnection handling
• Built-in group messaging (broadcast to specific users/rooms)
• Multiple scaling options (Redis, Azure Service Bus, SQL Server)
• Cross-platform client SDKs

// Bad - Polling for updates
public class DashboardController : Controller
{
    [HttpGet("api/dashboard/stats")]
    public async Task<IActionResult> GetStats()
    {
        // Client calls this every 5 seconds - wasteful!
        var stats = await _statsService.GetCurrentStats();
        return Ok(stats);
    }
}

// Client-side polling
setInterval(async () => {
    const response = await fetch('/api/dashboard/stats');
    const stats = await response.json();
    updateDashboard(stats);
}, 5000);

❌ Figure: Bad example - Polling wastes resources even when nothing has changed

// Good - SignalR Hub for real-time updates
public class DashboardHub : Hub
{
    public async Task SubscribeToDashboard(string dashboardId)
    {
        await Groups.AddToGroupAsync(Context.ConnectionId, $"dashboard-{dashboardId}");
    }
}

// Service that pushes updates only when data changes
public class StatsService
{
    private readonly IHubContext<DashboardHub> _hubContext;

    public async Task UpdateStats(string dashboardId, DashboardStats stats)
    {
        // Only sends when there's actually new data
        await _hubContext.Clients.Group($"dashboard-{dashboardId}")
            .SendAsync("StatsUpdated", stats);
    }
}

✅ Figure: Good example - SignalR pushes updates only when data actually changes

When to use Server-Sent Events (SSE)

SSE is perfect when you only need server-to-client communication and want zero dependencies:

• Live notifications
• Activity feeds
• Stock tickers
• Log streaming

// Good - SSE for simple server-to-client streaming
[HttpGet("api/notifications/stream")]
public async Task StreamNotifications(CancellationToken cancellationToken)
{
    Response.Headers.Append("Content-Type", "text/event-stream");
    Response.Headers.Append("Cache-Control", "no-cache");

    await foreach (var notification in _notificationService
        .GetNotificationsAsync(cancellationToken))
    {
        await Response.WriteAsync($"data: {JsonSerializer.Serialize(notification)}\n\n");
        await Response.Body.FlushAsync();
    }
}

✅ Figure: Good example - SSE provides a lightweight option for unidirectional streaming

When to use raw WebSockets

Use WebSockets directly when you need:

• Maximum performance with minimal overhead
• Binary data transmission (games, media streaming)
• Custom protocols or message formats
• Non-.NET clients where SignalR isn't available

When live connections are overkill

Live connections add complexity. Sometimes they're not worth it.

Consider simpler alternatives when:

• Updates are infrequent - If data changes hourly or daily (e.g., daily reports, software update checks), scheduled polling or manual refresh is fine
• Near real-time is acceptable - A 30-second delay does not impact the user experience (e.g., email inbox, social media feeds)
• The app is internal with few users - 5 users polling every 10 seconds is just 30 requests/minute - hardly a scaling concern
• You are building a prototype or MVP - Get it working first, optimize later when you have real usage data
• Infrastructure does not support WebSockets - Some corporate proxies, firewalls, or legacy systems block WebSocket connections

Quick decision flowchart

Ask yourself these questions:

1. Do users need updates instantly (less than 1 second)? - Use SignalR or WebSockets
2. Is it server-to-client only? - Consider SSE for simplicity
3. Are you in the .NET ecosystem? - SignalR is the default choice
4. Do you need maximum performance/binary data? - Raw WebSockets
5. Is near real-time (30+ seconds) acceptable? - Polling is fine
6. Is this an MVP or prototype? - Start simple, optimize later

Scaling considerations

Live connections maintain persistent server connections, which introduces state into your web tier. When scaling horizontally:

• SignalR: Use a backplane (Redis, Azure Service Bus, or SQL Server)
• Azure SignalR Service: Managed service that handles scaling automatically
• WebSockets: Configure load balancers for sticky sessions or use a message broker

// Program.cs - Configuring SignalR with Redis backplane for scaling
builder.Services.AddSignalR()
    .AddStackExchangeRedis(connectionString, options =>
    {
        options.Configuration.ChannelPrefix = RedisChannel.Literal("MyApp");
    });

✅ Figure: Good example - Configure a backplane when scaling SignalR horizontally

Summary

Further reading

• Introduction to SignalR | Microsoft Learn
• SignalR vs WebSocket comparison | Ably
• Server-Sent Events in ASP.NET Core | Roxeem
• Stop Polling and Consider Using REST Hooks | Nordic APIs
• Webhooks vs Polling | Merge