From Batch to Real-Time: How We Helped a Logistics Startup Track 10,000 Shipments with a Vietnamese AI-Augmented Team

“Your tracking system is broken.”

That’s the exact message our client—let’s call them LogiTrack—received from their biggest enterprise customer one Thursday morning. And they weren’t wrong.

How Agentic AI Is Changing the Way Developers Actually Work (A Practical Guide)

Agentic AI for developer workflows isn’t just another buzzword. It’s a shift from passive code completion to autonomous… ...

Read more

LogiTrack is a B2B logistics startup based in the US. They offer a white-label tracking API that lets e-commerce brands show delivery status to their end customers. By the time they reached us, they were handling roughly 10,000 active shipments per day. Their system? A batch processor that synced shipment updates every 60 minutes.

Here’s the problem. When a tracking event happened (package scanned, driver assigned, delivery confirmed), it sat in a queue for up to an hour before the API reflected it. End customers saw stale data. Support tickets piled up. The churn rate hit 8% per quarter.

How a Legacy Enterprise Cut Processing Time by 70% with AI Digital Transformation

TL;DR: This case study shows how a 30-year-old logistics company leveraged AI digital transformation to automate document processing,… ...

Read more

We were brought in to fix this mess. The budget was tight. The timeline was brutal—six weeks.

This is the story of how we rebuilt their core tracking pipeline from scratch. We used a team of four Vietnamese developers (two senior, two middle), the ECOA AI Platform ACP for orchestration, and a very opinionated architecture.

It worked. Here’s why.

The As-Is Architecture: Why Batch Failed

Let’s be honest. Batch processing isn’t always bad. If you’re doing payroll or nightly report generation, it’s fine. But for real-time tracking? It’s a nightmare.

LogiTrack’s original system looked like this:

• Ingestion: A cron job ran every 60 minutes, pulling tracking events from two carrier APIs via REST.
• Storage: All events landed in a single PostgreSQL table. No indexing schema for time-series queries.
• API: A single REST endpoint (`GET /api/v1/tracking/{id}`) queried PostgreSQL directly. Average response time: 30 seconds.
• Notifications: None. Customers had to poll.

The architectural sin here wasn’t just latency. It was coupling. The ingestion pipeline, the database, and the API were all interdependent. If one carrier API was slow, the entire system blocked.

The metric that hurt most: 95th percentile API latency was 45 seconds. That’s not a typo.

The Target: Sub-Second Reads, Sub-Second Writes

Our client gave us three hard requirements:

1. API P99 latency under 1 second for single-tracking lookups.
2. Event ingestion latency under 5 seconds from carrier webhook to API reflection.
3. Zero data loss. No compromises.

Budget: $12,000/month for the team (2 seniors at $3,000/month each, 2 middles at $2,000/month each). That’s the ECOA AI rate. Compare that to a US-based team where the same four developers would cost at least $50,000/month.

We had the talent. We had the platform. Here’s what we built.

The Rewrite: Event-Driven, Real-Time, AI-Augmented

We had exactly six weeks. A traditional rewrite would take six months. We couldn’t afford that luxury.

Instead, we used the ECOA AI Platform ACP to orchestrate the work. Here’s the critical insight: we didn’t give our developers instructions like “build a real-time pipeline.” We broke the work into granular, parallelizable tasks and used intelligent agents to accelerate coding, testing, and code review.

Step 1: Data Model Migration (Week 1)

First, we needed a database that could handle time-series tracking events without locking. We migrated from a single PostgreSQL table to a hybrid architecture:

• PostgreSQL: Still the source of truth for shipment metadata (origin, destination, customer ID).
• Redis: Serves as the primary read layer. Tracking events are stored as sorted sets with timestamps as scores. This gives us O(log N) lookups.

Why not TimescaleDB or ClickHouse? Honestly, we considered it. But the team in Ho Chi Minh City had deep Redis expertise from previous projects. More importantly, the ECOA AI Platform ACP’s built-in caching patterns let us auto-generate the Redis read-backed logic in under two days.

Here’s the schema we ended up with:

PostgreSQL: shipments (id, customer_id, origin, destination, status, created_at)
Redis: tracking:{shipment_id} -> sorted set of (timestamp, event_json)
Redis: recent_events -> sorted set of (timestamp, shipment_id) for global queries

Step 2: Event Ingestion Pipeline (Weeks 2-3)

This was the hardest part. We had to replace the cron-driven ingestion with a webhook-based system that could handle both HTTP callbacks and polling fallbacks for carriers that don’t support webhooks.

The architecture:

• NGINX + FastAPI sits in front, handling carrier webhooks. Each webhook payload is validated and published to a Kafka topic.
• Apache Kafka is the central event bus. We created two topics: `tracking-events` and `dead-letter-events`.
• A Kafka consumer (written in Python, running on Kubernetes) processes events in batches of 100. It writes to both PostgreSQL and Redis within a single transaction.

The tricky part? Carrier APIs are unreliable. One carrier sends duplicate events. Another sends events out of order. A third sometimes drops webhooks entirely.

We solved this with a deduplication layer inside the Kafka consumer. Each event carries a carrier-provided `event_id`. We maintain a Bloom filter in Redis to check for duplicates before processing. False positives are handled by a secondary hash set with a TTL of 24 hours.

python
import redis
import mmh3

class Deduplicator:
    def __init__(self, redis_client: redis.Redis, ttl: int = 86400):
        self.r = redis_client
        self.ttl = ttl

    def is_duplicate(self, event_id: str) -> bool:
        key = f"dedup:{mmh3.hash128(event_id)}"
        if self.r.get(key):
            return True
        # Set with TTL in seconds (24h)
        self.r.set(key, "1", ex=self.ttl)
        return False

But this logic wasn’t hand-written by a developer staring at a blank screen. It was generated and suggested by an AI agent running inside the ECOA ACP. The developer reviewed it, tuned the TTL, and committed it. What would have taken two days of writing and debugging was done in four hours.

Step 3: Real-Time API Layer (Weeks 3-4)

The API needed to be fast. Really fast.

We built it as a FastAPI service that reads from Redis first, with PostgreSQL as a fallback. Here’s the flow:

1. Client calls `GET /api/v1/tracking/{shipment_id}`.
2. API checks Redis sorted set `tracking:{shipment_id}` for the latest 10 events.
3. If Redis miss, it queries PostgreSQL and asynchronously backfills Redis.
4. Response time: 400ms P99.

We also added a WebSocket endpoint for real-time push. It uses Redis Pub/Sub internally. When a new tracking event is ingested, it’s published to a channel named `ws:{shipment_id}`. The FastAPI WebSocket handler subscribes to that channel. No polling on the client side.

This was the moment the client’s eyes widened. They demoed it to their enterprise customer. The customer said, “This is what we expected from day one.”

Step 4: AI-Augmented Code Review (Continuous)

We didn’t just use AI for code generation. We used it for code review. Every PR was automatically analyzed by an ACP-powered review agent. It caught:

• Two race conditions in the Kafka consumer where event ordering wasn’t guaranteed.
• One Redis connection leak that would have caused a production outage within 48 hours.
• Three performance anti-patterns in SQL queries that would have degraded over time.

Let me be blunt: a human reviewer would have caught these too. But not within the 6-week timeline. The AI review agent cut review cycle time from 2 days to 4 hours per PR.

The Results: Hard Numbers

This is the part I love. Here’s what we shipped at the end of 6 weeks:

Team cost: $12,000/month for the 4-person Vietnamese AI-augmented team. A US-based team with similar output would have cost approximately $55,000/month.

Development speed: 6 weeks from spec to production. The client’s CTO later told us, “I estimated 5 months with a full-time US team.”

Why This Matters for CTOs

You might be thinking, “This is just another outsourcing success story.” But it’s not.

The real differentiator here wasn’t the cost savings—although $43,000/month is hard to ignore. It was the AI-augmentation that let a small, remote team move like a much larger one. Our Vietnamese developers weren’t just following orders. They were using the ECOA AI Platform ACP to generate, test, and validate code at a pace that would be impossible manually.

Honestly, I’ve been doing this for 15 years. I’ve never seen a remote team deliver this cleanly, this fast.

And here’s the kicker: LogiTrack has kept the same team on retainer. They’re now building their second product—a real-time analytics dashboard—using the same developers, the same platform, and the same playbook.

It works. Don’t take my word for it. Try it yourself.

—

Frequently Asked Questions

Q: How did you handle carrier APIs that don’t support webhooks?

A: We built a polling fallback service that runs every 30 seconds for carriers without webhook support. It uses exponential backoff and writes events into the same Kafka topic. The deduplication layer ensures no duplicates even if a webhook and a polled event arrive simultaneously.

Q: What was the most technically difficult part of the migration?

A: The data migration from the old PostgreSQL schema to the new hybrid Redis + PostgreSQL system. We had to backfill 3 months of historical tracking events without downtime. We used a batch script that processed 1,000 shipments per batch with a 500ms sleep between batches to avoid connection pool exhaustion.

Q: Can this architecture scale beyond 10,000 shipments?

A: Yes. We load-tested up to 100,000 concurrent shipments using a simulated carrier cluster. The bottleneck was the single Kafka partition. For higher throughput, you’d partition the `tracking-events` topic by `shipment_id` hash and add more consumers. Redis clustering would also be required beyond 50,000 active shipments.

Q: How do you ensure the Vietnamese developers stay aligned with US time zones?

A: Our team in Ho Chi Minh City and Can Tho overlaps with US Eastern time from 7 PM to 11 PM local time. For critical issues, we use a follow-the-sun model with shared on-call rotation. The ECOA AI Platform ACP’s asynchronous task management means most feedback loops are non-blocking.

Related reading: Vietnam Outsourcing Is Overhyped? Here’s Why Enterprise Tech Leaders Are Betting on It

Related reading: Outsourcing Software Development: What Every CTO Needs to Know in 2025