Business Application

AI Agents

quincy

Home » How to build real-time delivery tracking with Azure Maps and SignalR

How to build real-time delivery tracking with Azure Maps and SignalR

Rohit Dabra | March 30, 2026

Building real-time delivery tracking with Azure Maps and SignalR is one of those projects that looks simple until you're 40 hours in, wondering why your map pin jumps backward three blocks every time a GPS packet arrives out of order. Customers expect a live pin that moves smoothly. Dispatchers expect a status board that updates the moment a driver marks an order picked up. The backend needs to do all of this across dozens or hundreds of drivers without burning through memory or crashing under WebSocket load.

This guide covers the full architecture, from SignalR hub configuration to Azure Maps rendering, with honest notes on cost, scaling, and the tradeoffs most tutorials skip.

What Makes Live Delivery Tracking Hard to Get Right

The obvious part is showing a dot on a map. The hard part is everything underneath: handling dropped connections, preventing location data from arriving out of sequence, keeping memory usage flat as the driver count grows, and doing it all at a cost that makes sense for the business.

Traditional polling approaches, where the client calls the server every few seconds to ask "anything new?", work at small scale but fall apart quickly. With 200 drivers, a 3-second poll interval means 200 HTTP requests hitting your backend every 3 seconds. That's 4,000 requests per minute just for location updates, before any orders, status changes, or customer queries. Your database sees all of it. Your server costs grow with it.

WebSocket-based systems flip the model. The server pushes updates to clients when something changes. No polling. No redundant requests. This is exactly what Azure SignalR Service handles, and it's why it's the right choice for this architecture.

The Azure Services That Power Real-Time Delivery Tracking with Azure Maps and SignalR

A working real-time tracking system on Azure typically uses five services together:

Azure SignalR Service: Manages WebSocket connections at scale, so your application server doesn't hold thousands of open sockets
Azure Maps: Renders maps, handles geocoding, and supports route overlays via its Web SDK
Azure App Service: Hosts your .NET backend (or Node.js if that's your stack)
Azure SQL or Cosmos DB: Stores order state, driver profiles, and delivery history
Azure Service Bus (optional but recommended): Decouples GPS event ingestion from the SignalR broadcast so spikes don't overwhelm the hub

If you've read our guide on location-based app development with Azure Maps: 5 SMB use cases, you'll recognize some of these patterns. The difference here is that we're wiring them together for a live, bidirectional system rather than static queries.

Setting Up the SignalR Hub for a Delivery Tracking App

Create the Azure SignalR Service Resource

Start in the Azure portal. Create a SignalR Service resource in the same region as your App Service. Choose Serverless mode if your backend is Azure Functions, or Default mode if you're hosting a persistent .NET Hub class. For most SMB delivery apps with a dedicated backend, Default mode is simpler.

The service gives you a connection string. Store it in Azure Key Vault or your App Service application settings. Never hardcode it in source code.

Define the Hub Class

In your .NET backend, define a Hub class that scopes messages to the right recipients:

public class TrackingHub : Hub
{
 public async Task SendLocation(string driverId, double lat, double lng)
 {
 await Clients.Group($"order_{driverId}").SendAsync("ReceiveLocation", lat, lng);
 }

 public async Task JoinOrderGroup(string orderId)
 {
 await Groups.AddToGroupAsync(Context.ConnectionId, $"order_{orderId}");
 }
}

The key design here is groups, not broadcast. When a customer opens their tracking page, their browser joins the group for their specific order. Only the driver assigned to that order pushes updates to that group. This keeps message volume manageable and prevents customers from receiving each other's location data.

Connect the Mobile Driver App

The driver's mobile app needs to send GPS coordinates at a regular interval, typically every 3 to 5 seconds. Sending more frequently than that rarely improves the user experience and increases your SignalR message volume.

The driver app connects to the SignalR hub, authenticates via Azure AD B2C or a JWT token, and calls SendLocation each time the device GPS fires. If you're building the mobile client and haven't chosen a framework yet, check out React Native vs Flutter: 5 factors SMBs should weigh in 2026 before you start.

Eager to discuss about your project?

Share your project idea with us. Together, we’ll transform your vision into an exceptional digital product!

Book an Appointment now

Rendering Live Tracking with Azure Maps

Initialize the Azure Maps Control

On the customer-facing web page, load the Azure Maps Web SDK and initialize a map centered on the delivery area:

const map = new atlas.Map('mapDiv', {
 center: [-122.33, 47.6],
 zoom: 13,
 authOptions: {
 authType: 'subscriptionKey',
 subscriptionKey: '<your-key>'
 }
});

Use a subscription key for quick prototyping, but switch to Azure AD authentication before going to production. Exposing a subscription key in client-side JavaScript is a real security risk: anyone who views your page source can extract it.

Add a Driver Marker and Update It in Real Time

Create a data source and a symbol layer for the driver pin. When SignalR fires a ReceiveLocation event, update the data source rather than creating a new marker. Creating new DOM elements on every GPS update will tank browser performance after a few minutes.

const dataSource = new atlas.source.DataSource();
map.sources.add(dataSource);

const driverPoint = new atlas.data.Feature(new atlas.data.Point([lng, lat]));
dataSource.add(driverPoint);

connection.on('ReceiveLocation', (lat, lng) => {
 driverPoint.geometry.coordinates = [lng, lat];
 dataSource.setShapes(driverPoint);
});

For a dispatcher dashboard showing all active drivers, keep a dictionary of driverId -> Feature and update each driver's coordinates in place.

Smooth Movement Between GPS Updates

Raw GPS coordinates jump. A driver traveling at 30 mph moves about 44 meters per second, and GPS accuracy varies by device and signal strength. You can smooth this with linear interpolation on the client side: instead of snapping the pin to the new coordinate instantly, animate it across 3 to 5 frames using requestAnimationFrame. The Azure Maps SDK doesn't include this natively, but about 20 lines of JavaScript handles it cleanly.

SignalR vs. Polling: The Real Performance Difference

This comparison comes up in nearly every evaluation. Here are the numbers that actually matter for a 100-driver deployment:

Metric	Polling (3s interval, 100 drivers)	SignalR WebSocket
Requests/minute to server	~2,000	~0 (push-based)
Server CPU during idle periods	Constant	Near zero
Location update latency	0-3 seconds	Under 100ms
Connection overhead	Per-request HTTP	One persistent socket

The latency gap is what customers notice. With polling, a driver who marks an order delivered takes up to 3 seconds to show that status on the customer's screen. With SignalR, it's under 100ms. For a food delivery app where customers are watching for that status change, the difference affects how they perceive the product.

The tricky part is reconnection. SignalR's .NET and JavaScript clients both include automatic reconnect with exponential backoff. But you still need to handle the case where a driver loses connectivity for several minutes and then reconnects. Store the last known location in Redis or Cosmos DB so the customer's map doesn't go blank during a reconnect.

Bar chart comparing requests per minute: polling at approximately 2000 per minute versus SignalR at near-zero for 100 concurrent drivers, illustrating the infrastructure cost impact at scale - real-time delivery tracking with Azure Maps and SignalR

Scaling Real-Time Tracking to Handle Thousands of Drivers on Azure

Azure SignalR Service handles connection scaling for you, which is the main reason to use the managed service instead of running your own hub. A single Standard tier instance supports 1,000 concurrent connections. Need more? Add units: each unit adds 1,000 connections and pricing scales linearly.

For the application server, the bottleneck shifts from connection count to message throughput as you grow. A few patterns that help:

Filter updates server-side. If a driver hasn't moved more than 10 meters since the last broadcast, skip sending the update.
Use Service Bus for ingestion. Put GPS updates on a Service Bus queue and let a consumer read from it to call the hub. This decouples ingestion from broadcasting and absorbs volume spikes.
Cache driver state in Redis. Keep current driver positions in Azure Cache for Redis rather than hitting SQL on every location update. Persist to SQL every 30 seconds or on status changes.
Shard by geography. If you operate across multiple cities, deploy separate hub instances per region and route drivers to the nearest one.

Eager to discuss about your project?

Share your project idea with us. Together, we’ll transform your vision into an exceptional digital product!

Book an Appointment now

Connecting Tracking Data to Power BI for Dispatcher Dashboards

Real-time maps work well for customers, but dispatchers need aggregate views: how many drivers are active right now, which zones have coverage gaps, which orders are running more than 15 minutes late.

You can stream tracking events to Power BI streaming datasets via the REST API. Each GPS event that lands in Service Bus can trigger an Azure Function that pushes a row to Power BI. The dataset refreshes in real time without scheduled refresh jobs.

Our post on Power BI dashboards for SMBs: 7 KPIs worth tracking covers dashboard design in detail. For a delivery operations context, five metrics drive most decisions:

Active drivers vs. active orders (supply and demand balance)
Average pickup-to-delivery time by zone
Percentage of deliveries exceeding the promised window
Driver idle time by shift
Order completion rate per driver

Azure Maps vs. Google Maps for Delivery Apps

Teams sometimes ask whether Azure Maps or Google Maps is the better choice for a logistics app. The honest answer depends on your existing agreements and requirements:

Factor	Azure Maps	Google Maps Platform
Pricing model	Pay-per-transaction; Azure credits apply	Pay-per-request; $200/month free tier
Enterprise licensing	Often included in MSDN/E5 agreements	Separate billing always
.NET SDK quality	Strong, first-party support	Community libraries
Map data coverage	Good in US/EU, thinner in emerging markets	Excellent globally
Azure AD integration	Native	Manual OAuth wiring
Real-time traffic	Yes	Yes

If your business already runs on Azure and holds Microsoft enterprise agreements, Azure Maps pricing usually works out cheaper. The model charges per tile render and per geocoding call, and those costs are predictable. Google Maps charges per API call, and the $200/month free tier disappears quickly under delivery app load.

One honest limitation: Azure Maps' route rendering for complex multi-stop deliveries is less mature than Google Maps' Directions API. If your dispatchers need sophisticated route optimization rather than just display, you may want to pair Azure Maps with a dedicated routing engine.

For teams evaluating broader cloud costs across providers, our comparison of Azure vs AWS vs Google Cloud: what startups actually pay gives a fuller picture of where each platform's costs actually land.

What This Architecture Costs an SMB

Let's put numbers on a realistic SMB deployment: 50 active drivers, 500 concurrent customer tracking sessions, running 8 hours per day.

Azure SignalR Service (Standard, 1 unit): ~$49/month
Azure Maps: ~$25/month at 500 sessions with 100 tile loads each
Azure App Service (P1v3): ~$138/month
Azure Cache for Redis (C1 Basic): ~$55/month
Azure Service Bus (Standard): ~$10/month

Total: roughly $277/month for a 50-driver system. That number drops with Dev/Test pricing and tile caching optimizations.

For context, most commercial fleet tracking SaaS products charge $15 to $30 per vehicle per month. At 50 drivers, that's $750 to $1,500 per month, and you still don't own the infrastructure or the data. The custom build costs more upfront but breaks even relatively quickly as driver count grows.

One tradeoff worth naming: building this system requires .NET or Node.js development resources. If your team is small and you need something running in two weeks, a SaaS option evaluated first is reasonable. The Azure build makes more sense once you have product-market fit and are scaling driver count past the point where SaaS per-seat pricing stings.

Handling Offline Tracking and Reconnection

The driver's phone loses signal. This happens in tunnels, parking garages, and rural delivery areas. Here's how to handle it without breaking the customer experience:

The SignalR client on the driver app detects the disconnect and queues GPS coordinates locally in memory (or in SQLite for longer outages).
On reconnect, the app sends the queued coordinates in order, with their original timestamps.
The backend writes them to Cosmos DB using the original timestamps, not the reconnect time.
The customer's tracking page shows the last known position with a clear signal-lost indicator rather than removing the pin entirely.

For most delivery apps, in-memory queuing is enough. Drivers rarely lose signal for more than 30 to 60 seconds, and the queue stays small.

Conclusion

Real-time delivery tracking with Azure Maps and SignalR is achievable for SMBs at a realistic cost, but the implementation details matter. Use SignalR groups to scope updates to the right audience. Update Azure Maps data sources in place rather than recreating markers on every GPS event. Decouple GPS ingestion with Service Bus when driver counts grow past a few dozen. Cache driver state in Redis to keep your database out of the high-frequency update path.

This architecture also integrates naturally with the rest of an Azure stack: Power BI for operations dashboards, Azure AD B2C for authentication, and Azure API Management for external partner integrations. If you're ready to start building or want a technical review of your current tracking setup, get in touch with our team.

Written by Rohit Dabra

Co-Founder and CTO, QServices IT Solutions Pvt Ltd

Rohit Dabra is the Co-Founder and Chief Technology Officer at QServices, a software development company focused on building practical digital solutions for businesses. At QServices, Rohit works closely with startups and growing businesses to design and develop web platforms, mobile applications, and scalable cloud systems. He is particularly interested in automation and artificial intelligence, building systems that automate routine tasks for teams and organizations.

Talk to Our Experts

Frequently Asked Questions

How do I implement real-time driver tracking using Azure Maps and SignalR?

Set up an Azure SignalR Service hub in your .NET backend and define a Hub class that uses groups to scope location updates to the correct audience. Each customer’s browser joins the group for their specific order. The driver’s mobile app authenticates and sends GPS coordinates to the hub every 3 to 5 seconds. On the frontend, use the Azure Maps Web SDK with a DataSource and update the driver marker in place on each ReceiveLocation event rather than creating a new marker each time.

What is the best architecture for a live delivery tracking system on Azure?

The recommended architecture combines Azure SignalR Service for WebSocket connection management, Azure Maps for map rendering and geocoding, Azure App Service to host the .NET backend hub, Azure Cache for Redis to cache current driver positions, and Azure Service Bus to decouple GPS event ingestion from broadcasts. This keeps your SQL database out of the high-frequency update path and gives you a buffer for GPS volume spikes.

How does SignalR enable real-time location updates in a logistics app?

SignalR maintains persistent WebSocket connections between the server and connected clients. When a driver sends a GPS coordinate to the hub, the hub immediately pushes that update to all clients in the relevant group, such as the customer and dispatcher tracking that specific order. This eliminates polling and reduces location update latency from seconds to under 100 milliseconds.

Can SMBs afford to build a real-time tracking platform on Azure?

Yes. A 50-driver system running on Azure costs roughly $277 per month, covering Azure SignalR Service, Azure Maps, App Service, Redis cache, and Service Bus. Commercial fleet tracking SaaS products typically charge $15 to $30 per vehicle per month, which totals $750 to $1,500 per month for 50 drivers. The custom Azure build costs more upfront but breaks even relatively quickly as driver count grows.

What is the difference between Azure Maps and Google Maps for delivery apps?

Azure Maps integrates natively with Azure AD, applies Azure credits toward usage costs, and is often included in Microsoft enterprise agreements, making it cost-effective for Azure-first organizations. Google Maps has broader global coverage and a more mature route optimization API. Azure Maps is usually the better choice for SMBs already running on Azure. For complex multi-stop routing or operations in emerging markets, Google Maps may have an edge.

How do I scale a real-time tracking system to handle thousands of concurrent drivers?

Azure SignalR Service scales by adding units, each supporting 1,000 concurrent connections in the Standard tier. On the application side, filter GPS updates server-side before broadcasting (skip updates where the driver has moved less than 10 meters), route GPS events through Azure Service Bus to decouple ingestion from broadcasting, cache driver state in Redis, and shard hub instances by geographic region for large multi-city deployments.

How do I handle offline tracking and reconnection in a SignalR-based delivery app?

The SignalR client libraries for .NET and JavaScript include automatic reconnect with exponential backoff. For the driver app, queue GPS coordinates locally when disconnected (in memory for short outages, in SQLite for longer ones) and flush the queue with original timestamps on reconnect. Store the last known driver position in Redis or Cosmos DB so the customer-facing map shows the last known location with a signal-lost indicator during disconnection rather than removing the pin entirely.