How did you handle WebSocket reconnection?

Client reconnection with exponential backoff and session persistence via Redis.

What was the infrastructure cost?

$50k/month for 50 Kafka brokers + 20 FastAPI instances + Redis cluster.

How does this case study work?

Raise a request, talk to experts, fund the project, expert works, review and approve payment. All remote, all through our platform.

Building Real-Time Data Platforms with FastAPI

Executive Summary

A global logistics company needed real-time tracking across 1M daily shipments. FastAPI with WebSockets and Kafka streaming delivered 500K events/second processing with 200ms end-to-end latency, enabling live customer tracking for the first time.

Key Outcomes

▹ 500K events/second sustained throughput
▹ 200ms end-to-end tracking latency
▹ 99.99% uptime since launch

Client Situation

Customers demanded live tracking, but existing system updated positions every 5 minutes—too slow for time-sensitive freight.

Key Challenges

⚠ GPS updates from 50K trucks arriving at 10Hz (500K events/sec)
⚠ Requirement for sub-second customer updates via WebSocket
⚠ Need to store and query historical tracking data

Existing Architecture

Batch processing updating PostgreSQL every 5 minutes. No real-time capability.

5-minute update delay unacceptable
Can't handle 500K events/sec throughput
No WebSocket support

Solution Design

FastAPI WebSocket gateway + Kafka streaming + Redis state store + PostgreSQL archive.

Key Decisions

✓ FastAPI for WebSocket management (10K concurrent connections)
✓ Kafka for event streaming (500K/sec)
✓ Redis for latest location (sub-ms lookups)

FastAPIKafkaRedisPostgreSQLWebSockets

Implementation

Phased rollout starting with 1% of trucks, expanding to 100% over 3 months.

Phase 1: Phase 1: Event Ingestion
Kafka pipeline ingesting 500K GPS events/sec from 50K trucks.
Phase 2: Phase 2: WebSocket Gateway
FastAPI managing 10K concurrent customer WebSocket connections.
Phase 3: Phase 3: Historical Store
PostgreSQL archive with partitioning for 1B+ tracking records.

Technical Challenges

WebSocket connection management at scale

Impact: 10K concurrent connections exhausting server resources

Resolution: Horizontal scaling with Redis pub/sub for cross-node communication

Kafka consumer lag during peaks

Impact: Latency spiking to 2 seconds during 500K/sec bursts

Resolution: Increased partitions (50) and consumers (50) for parallelism

Results

Event throughput: BeforeNot possible
After500K/sec
ImprovementNew capability
End-to-end latency (P99): Before5 minutes
After200ms
Improvement99.99% reduction
Concurrent WebSocket connections: Before0
After10,000
ImprovementNew capability

Lessons Learned

📘 FastAPI WebSocket performance exceeded expectations (10K connections per instance)
📘 Kafka partitioning by truck_id ensured ordering
📘 Redis as state store provided sub-ms latest location lookups

What We Would Do Differently

💡 Use Kafka tiered storage for longer retention
💡 Implement client-side throttling for high-update shipments

Role Relevance

FastAPI experts built the WebSocket gateway that kept 10K customers connected simultaneously while processing 500K events/sec—enabling real-time tracking at scale.

Critical Skills Demonstrated

WebSocket managementEvent streaming (Kafka)Real-time architecturesHorizontal scaling

Frequently Asked Questions

How did you handle WebSocket reconnection?: Client reconnection with exponential backoff and session persistence via Redis.
What was the infrastructure cost?: $50k/month for 50 Kafka brokers + 20 FastAPI instances + Redis cluster.