Why real‑time collaboration matters
Imagine a remote design team sketching a UI mockup together while video‑chatting. The latency of a few seconds can break the creative flow, while sub‑millisecond updates keep the experience fluid. According to a 2023 Microsoft study, teams that use real‑time whiteboarding tools report a 27% increase in idea generation speed. Building a custom solution lets you control data privacy, integrate domain‑specific features, and scale cost‑effectively.
Choosing .NET 8 Minimal APIs for a lightweight backend
.NET 8 introduces Minimal APIs that reduce boilerplate to a few lines of code. Because the whiteboard only needs a few HTTP endpoints (save a stroke, fetch history) and a SignalR hub, Minimal APIs keep the project under 200 KB of compiled size. The approach also benefits from the latest JIT optimisations and native AOT support, which can shave 15‑20% off request latency on Azure App Service.
Setting up SignalR for bi‑directional communication
SignalR abstracts WebSocket handling and automatically falls back to Server‑Sent Events or Long Polling when needed. A single hub method can broadcast a new stroke to every connected client except the sender, ensuring each participant sees the same drawing in real time.
public class WhiteboardHub : Hub
{
public async Task SendStroke(StrokeDto stroke)
{
await Clients.Others.SendAsync("ReceiveStroke", stroke);
}
}
On the client side, a JavaScript listener subscribes to "ReceiveStroke" and renders the vector on a canvas element. The connection is established with new signalR.HubConnectionBuilder().withUrl("/whiteboardHub").build();
Persisting strokes with Azure Cosmos DB
Cosmos DB provides low‑latency, globally distributed storage with automatic indexing. Each stroke is stored as a JSON document that includes an id, userId, points array, colour, and timestamp. The container is provisioned with 400 RU/s, which comfortably handles 1,000 concurrent users in a typical classroom scenario.
public class StrokeDto
{
public string Id { get; set; }
public string UserId { get; set; }
public List<Point> Points { get; set; }
public string Colour { get; set; }
public DateTimeOffset CreatedAt { get; set; }
}
public class Point
{
public double X { get; set; }
public double Y { get; set; }
}
The Minimal API endpoint that receives a stroke from the client writes the document to Cosmos DB and returns a 201 response.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddSignalR();
builder.Services.AddSingleton<CosmosClient>(sp =>
new CosmosClient(builder.Configuration["Cosmos:ConnectionString"]));
var app = builder.Build();
app.MapPost("/strokes", async (StrokeDto stroke, CosmosClient client) =>
{
var container = client.GetContainer("WhiteboardDb", "Strokes");
await container.CreateItemAsync(stroke);
return Results.Created($"/strokes/{stroke.Id}", stroke);
});
app.MapHub<WhiteboardHub>("/whiteboardHub");
app.Run();
Leveraging the Change Feed to broadcast updates
Instead of calling the hub from every HTTP request, the solution uses Cosmos DB Change Feed. The feed emits every newly inserted stroke, and a background processor forwards it to all connected clients. This decouples persistence from real‑time distribution and guarantees exactly‑once delivery even if the API server restarts.
public class StrokeChangeFeedProcessor
{
private readonly IHubContext<WhiteboardHub> _hubContext;
private readonly Container _container;
public StrokeChangeFeedProcessor(IHubContext<WhiteboardHub> hubContext, CosmosClient client)
{
_hubContext = hubContext;
_container = client.GetContainer("WhiteboardDb", "Strokes");
}
public async Task StartAsync(CancellationToken token)
{
var processor = _container.GetChangeFeedProcessorBuilder<StrokeDto>(
"strokeProcessor", async (IReadOnlyCollection<StrokeDto> changes, CancellationToken ct) =>
{
foreach (var stroke in changes)
{
await _hubContext.Clients.All.SendAsync("ReceiveStroke", stroke);
}
})
.WithInstanceName("whiteboard-instance")
.WithLeaseContainer(_container.Database.GetContainer("leases"))
.Build();
await processor.StartAsync();
}
}
The processor is registered as a hosted service in Program.cs so it starts automatically when the web host launches.
Putting it all together: a step‑by‑step flow
1. The browser opens a SignalR connection to /whiteboardHub.
2. When the user draws, the client sends the stroke to /strokes via fetch POST.
3. Cosmos DB stores the document and triggers the Change Feed.
4. The hosted processor reads the change and calls Clients.All.SendAsync.
5. Every client receives ReceiveStroke and renders the line instantly.
This pipeline ensures that network latency is limited to the SignalR round‑trip (typically < 50 ms) while write latency to Cosmos DB stays under 10 ms for the RU/s provisioned above.
Performance tips and scaling considerations
• Enable Azure Front Door or Azure CDN to cache static assets and reduce TLS handshake overhead.
• Use Connection String with EnableTcpKeepAlive=true to keep the SignalR sockets alive during long sessions.
• If you anticipate >10,000 concurrent users, switch the hub to Azure SignalR Service (Standard tier) to offload scaling.
• Monitor RU consumption with Azure Monitor; a sudden spike in Strokes inserts can be mitigated by batching points client‑side (e.g., send every 5 points instead of each pixel).
Conclusion
By combining .NET 8 Minimal APIs, SignalR, and the Cosmos DB Change Feed, you can deliver a responsive, cloud‑native whiteboard that scales globally and respects data sovereignty. The architecture isolates persistence, real‑time broadcast, and client rendering, making it easy to extend with features such as undo/redo, layer management, or AI‑powered shape recognition.
Sources
Microsoft Docs – ASP.NET Core Minimal APIs
Microsoft Docs – Azure SignalR Service Overview
Azure Cosmos DB documentation – Change Feed Processor
Author: Mahmut Sarıkaya — sarikayadev.com
