Architecture of Order Tracking: Two Data Channels
The client opens the app 40 minutes after placing the order and sees the status "Processing"—the same as right after payment. They call support. The problem isn't logistics: the courier is already on the way, coordinates update on the server every 30 seconds. The issue is that the mobile app is not connected to that stream. We've encountered this in 80% of projects at the start. Our team has over 5 years of experience in building delivery mobile apps, and we have implemented more than 15 order tracking systems for e-commerce stores.
The status timeline and the courier map are two different mechanisms with different update requirements, and mixing them within one polling request is the first architectural mistake. We have already tested several approaches and identified optimal solutions for each channel.
Why Statuses and Coordinates Require Different Channels
Order status changes infrequently—5-7 times during the entire lifecycle. For this, long-polling or SSE (Server-Sent Events) works: connection stays open, server pushes an event only when the status changes. WebSocket is overkill here, though often chosen out of habit. Courier coordinates update every 15-30 seconds—this is a different load profile.
| Criteria | Polling | SSE | WebSocket |
|---|---|---|---|
| Frequency | Any | Rare events | Frequent events |
| Latency | Depends on interval | Low | Low |
| Complexity | Simple | Medium | High |
| Example | Order status | Timeline | Courier coordinates |
The average latency for status updates via SSE is less than 1 second, and for coordinates via WebSocket up to 200 ms.
How to Properly Implement the Timeline on the Client
On iOS, implementing SSE with URLSession looks like this:
let request = URLRequest(url: URL(string: "https://api.example.com/orders/\(orderId)/status-stream")!) let task = URLSession.shared.dataTask(with: request) { data, response, error in // parse text/event-stream line by line } task.resume() Better to use a ready-made library—IVALiveEventSource or the Swift Package swift-eventsource from LaunchDarkly. They handle reconnect and heartbeat properly.
On Android—OkHttp with EventSource from the library com.launchdarkly:okhttp-eventsource. Writing native HttpURLConnection for SSE manually is a waste of time handling edge cases.
Comparison of SSE libraries:
| Platform | Library | Advantages |
|---|---|---|
| iOS | IVALiveEventSource | Heartbeat support, automatic reconnect |
| iOS | swift-eventsource (LaunchDarkly) | Active community, Swift Package Manager compatibility |
| Android | okhttp-eventsource (LaunchDarkly) | Integration with OkHttp, ease of setup |
Timeline Structure on the Screen
For displaying the progress of statuses, use RecyclerView (Android) or UICollectionView with a custom layout (iOS). A typical mistake is storing "past" statuses only on the client. If the user uninstalls and reinstalls the app, the history is lost. All completed statuses with timestamps must be returned from the server as an array:
{ "currentStatus": "courier_assigned", "timeline": [ { "status": "created", "timestamp": "2025-01-01T10:00:00Z" }, { "status": "confirmed", "timestamp": "2025-01-01T10:02:30Z" }, { "status": "courier_assigned", "timestamp": "2025-01-01T10:15:00Z" } ] } How to Handle Courier Coordinates Separately
Courier coordinates update every 15-30 seconds—this is not SSE territory but WebSocket or a separate short-interval polling. Mixing it with the status timeline in one endpoint either overloads the status stream or updates the map too rarely.
In practice, we do this:
- Statuses - SSE or push notifications (Firebase Cloud Messaging)
- Courier coordinates - WebSocket with 15-30 second intervals or polling
/orders/{id}/courier-location
Smoothing the Courier Marker
The courier marker on the map jumps if you simply set new coordinates directly. The right way is to animate the movement between points. On Android via ValueAnimator:
val animator = ValueAnimator.ofFloat(0f, 1f).apply { duration = 1000 addUpdateListener { animation -> val fraction = animation.animatedValue as Float val lat = startLat + (endLat - startLat) * fraction val lng = startLng + (endLng - startLng) * fraction courierMarker.position = LatLng(lat, lng) } } animator.start() On iOS via CADisplayLink or UIView.animate with intermediate coordinates.
To rotate the courier icon in the direction of movement, use atan2(deltaLat, deltaLng)—remember to convert radians to degrees for marker.rotation.
What to Do When Connection Drops?
The user minimizes the app—WebSocket and SSE disconnect. Key status changes (courier picked up, courier nearby, delivered) are duplicated via FCM/APNs. On iOS use UNUserNotificationCenter, on Android FirebaseMessagingService.
A nuance: a "courier nearby" notification loses meaning if it arrives 10 minutes after delivery. The server must check event timeliness before sending a push—this is server-side logic, not mobile.
What's Included in the Work
- Status timeline with SSE or FCM pushes
- Courier map with animated marker (Google Maps SDK or MapKit)
- WebSocket or polling for coordinates with correct lifecycle (onPause/onResume / viewDidDisappear)
- Offline state handling: event queue and sync on network restore
- Code signing for push notifications (APNs and FCM)
Timelines
3–5 days for the full flow: timeline + map + pushes. Timeline only without map—1–2 days. The cost is calculated individually after requirements analysis.
Get a consultation on your project. We'll help you choose the optimal architecture for your delivery app. Request an estimate—it's free.