Back

Case Study · Tokopedia

Real-Time Inventory Sync

Sub-second consistency across 50M+ daily events

Scroll to explore

Company

Tokopedia

Timeline

6 months · 2022

Role

Lead Engineer

Team

5 Engineers

50M+

Daily Events

12

Microservices

−34%

Checkout Failures

<200ms

Latency p99

The Problem

Inventory was lying.

Tokopedia's marketplace had grown to host millions of SKUs across thousands of sellers. The legacy sync system — a batch-job cronjob — introduced 5–15 minute staleness windows. Customers regularly added out-of-stock items to cart, causing checkout failures and lost revenue. The core issue: a read-heavy system being updated through writes that couldn't keep up.

The Solution

Event-driven, not batch-driven.

We rebuilt the sync pipeline around a Kafka event bus. Every inventory mutation — sale, return, restock — emits an event immediately. Downstream consumers subscribe to the exact topics they care about. A Redis read-layer caches the materialized view, keeping API latency flat under load spikes.

  • Kafka topics per inventory domain (not a single firehose)
  • Idempotent consumers with at-least-once delivery guarantees
  • Redis Sorted Set for real-time availability windows
  • PostgreSQL as source of truth with WAL-level CDC

Results

The impact.

−34%

Checkout failure rate

5min → 80ms

Sync latency

50M+

Daily event throughput

99.97%

System uptime

Technology Stack

GoKafkaPostgreSQLRedisKubernetesgRPC
Done.

That's the story.

View on GitHub