How did the team decide not to use Kafka for live location updates of a delivery driver app?

Solvelyn tech — Wed, 04 Nov 2026 12:16:11 +0000

The project: Akaiva Edu Power
We are developing Akaiva Edu Power — a same-day delivery platform for books and stationery built for Akaiva Edu Private Limited. Orders placed before 11 am reach customers the same day. A small fleet of delivery drivers is tracked live on a map so customers can watch their delivery approach.

The default answer: Kafka
Whenever a room full of engineers hears the phrase "real-time location of delivery drivers", someone will immediately say Kafka. The reasoning is sound in principle:

Drivers emit location events at high frequency.
Many consumers (customer apps, dashboards, dispatch systems) may want to read those events independently.
Kafka's log-based architecture absorbs enormous write throughput and lets you replay history.

For a company like Swiggy, Dunzo, or Amazon Flex — with thousands of concurrent drivers — Kafka earns its complexity. But this is a startup, not a hyperscaler.

Our actual numbers:
Forty rows per minute into a location table. Postgres handles millions of rows per second in write-heavy OLTP workloads. There was simply no load problem to solve.

What Kafka would have cost us
Setting up Kafka (or a managed alternative like Confluent Cloud / AWS MSK) for this use case would have meant:

Infra overhead — a Kafka cluster, ZooKeeper (or KRaft), topic management, consumer group offsets. 2. Ops burden — monitoring lag, retention policies, partition rebalancing. 3. Developer complexity — producers, consumers, serialisation schemas (Avro/Protobuf), exactly-once semantics. 4. Cost — managed Kafka starts at roughly ₹6,000–₹15,000 per month at the smallest tier; a Postgres instance on the same cloud is a fraction of that. 5. Time — weeks of engineering that a 10-driver startup does not have budget for.

What we did instead
We kept it simple:

Drivers → POST /location → API route → Postgres upsert on driver id

The location table has one row per driver, updated in place every 50 seconds:

CREATE TABLE driver_locations (
driver_id UUID PRIMARY KEY REFERENCES drivers(id),
lat NUMERIC(9,6) NOT NULL,
lng NUMERIC(9,6) NOT NULL,
updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
The customer app polls GET /delivery/{order_id}/location every 30 seconds (or we push via a simple WebSocket channel for the 1–2 active deliveries at a time). The query is a single indexed primary-key lookup — sub-millisecond.

The lesson
Over-engineering is a form of waste. Choose the simplest solution that handles your actual load, with a clear upgrade path if that ever changes.
If Akaiva Edu ever scales to 500 drivers doing 5-second pings, the right move is to evaluate a message queue at that point — with real numbers, real costs and a team that has the bandwidth to operate it. Until then, Postgres is fast, reliable, cheap, and already in the stack.

About the author
Leena Wooledge is a Senior Software Developer at Akaiva Private Limited. She leads backend architecture decisions across the Akaiva Edu product suite.

At solvelyn.com we develop apps, websites, web apps and software with perfection. If you want your app or website to be built, contact here.

DEV Community: Solvelyn tech

How did the team decide not to use Kafka for live location updates of a delivery driver app?