SYSTEM Cited by 1 source
Nakadi¶
Definition¶
Nakadi (github.com/zalando/nakadi) is Zalando's open-source distributed event bus / event streaming platform. It wraps Apache Kafka with a REST-based publish / subscribe API, a schema registry, and per-event-type authorisation, so teams inside Zalando can produce and consume events without operating Kafka clients directly.
What makes it distinctive¶
- REST API over Kafka. Producers publish JSON events via HTTP POST to a Nakadi endpoint; consumers subscribe via HTTP long-poll. Hides Kafka protocol / partition management from application developers.
- Schema registry. Every event type has a declared JSON schema that Nakadi enforces at publish time — so consumers can rely on schema conformance.
- Partition + position management managed. Consumers track their offset via Nakadi's subscription API rather than directly managing Kafka offsets.
- Centrally managed inside Zalando — one shared event bus across the company.
Stub page — expand when a deeper Nakadi-focused source lands.
Seen in¶
- — named as a centrally managed event queue whose test- cluster deployment had to be adjusted for production-parity before the end-to-end Payment load tests could produce realistic throughput — called out as operational friction requiring cross-team alignment.
- sources/2026-03-16-zalando-search-quality-assurance-with-ai-as-a-judge — production-traffic-to-data-lake instance. "In our search infrastructure, every search request we get in the site is processed by our NER engine, served by our and Search API, and then published to an asynchronous event stream (powered by Nakadi, our RESTful event bus built on top of Kafka queues)." Data-Lake pipelines consume these search events, process them, and persist for OLAP analysis — the upstream substrate that feeds Zalando's Search Query Clustering pipeline and, by extension, the Search Quality Framework's test-query generator.
-
— Nakadi as the publication target of a transactional-outbox
relay. Zalando Payments's Order Store uses DynamoDB Streams +
AWS Lambda to publish data-change events to Nakadi off the
synchronous path. The prior coupled design's availability
ceiling was
99.9% × 99.9% = 99.8%because Nakadi was a must-succeed synchronous dependency; decoupling removes Nakadi from the sync path and restores99.9%. A Lambda-attached SQS DLQ + Kubernetes CronJob drains transient Nakadi publish failures back onto the bus — canonical example of designing around Nakadi's availability rather than depending on it. See patterns/transactional-outbox, patterns/dynamodb-streams-plus-lambda-outbox-relay, patterns/sqs-dlq-plus-cron-requeue. - — Nakadi as the ingress substrate + durable overflow buffer for AIMD admission control. Zalando's Communication Platform consumes 1,000+ Nakadi event types via its Stream Consumer — one Event Listener per event type, each backed by an AIMD throttle that slows or speeds up Nakadi consumption in response to RabbitMQ publish-side congestion signals. Un-consumed events sit on Nakadi ( Kafka-backed, durable) — making Nakadi the platform's overflow buffer during load episodes, with RabbitMQ queues staying small. Canonical instance of Nakadi's durable-log + per-event-type-subscription shape being load-bearing for load-shedding design. The post also names a concrete Nakadi quirk: "modifying the batch size is currently not supported natively by Nakadi" — so the Stream Consumer pauses/resumes consumption to approximate dynamic rate control, a client-side workaround for an API gap.