Skip to content
A distributed event bus that implements a RESTful API abstraction on top of Kafka-like queues
Java Other
  1. Java 99.8%
  2. Other 0.2%
Branch: master
Clone or download

Latest commit

adyach Merge pull request #1200 from Dmitry-Erokhin/add_clin_to_nakadi_docs
Added `Clin` tool to the clients list in the documentation
Latest commit 12c87f8 May 25, 2020

Files

Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.github Remove changelog. Use releases page instead for a list of changes. Oct 18, 2018
.idea restored codestyle Sep 23, 2019
acceptance-test create meter to track number of short circuiting per broker May 20, 2020
api-consumption Merge pull request #606 from lhotari/lh-reduce-ioexceptions May 19, 2020
api-cursors Revert "Revert "Update Kafka Clients to 2.3.0"" Feb 24, 2020
api-metastore Log class name if message is null May 12, 2020
api-misc Validate request body on POST /settings/features Apr 1, 2020
api-publishing Add tests, change interface name and exceptions Jan 27, 2020
app Checkstyle Mar 27, 2020
core-common Merge pull request #1198 from zalando/ARUHA-2884 May 25, 2020
core-metastore Revert "Revert "Update Kafka Clients to 2.3.0"" Feb 24, 2020
core-services create meter to track number of short circuiting per broker May 20, 2020
database Add index on owning application for subscription table Dec 23, 2019
docs Fixed case May 25, 2020
gradle/wrapper Bump gradle version Oct 11, 2018
plugins ARUHA-123: fix build Aug 17, 2016
.gitignore log level debug for kafka client Jan 4, 2019
.zappr.yaml aruha-747 zappr generated by compliance team May 3, 2017
CODE_OF_CONDUCT.md Correct Code of conduct (#728) Sep 20, 2017
CONTRIBUTING.md Fix typo Jun 19, 2017
Dockerfile build fat jar for tests Jan 14, 2020
LICENSE Initial commit Oct 14, 2015
MAINTAINERS Updated maintainers list May 29, 2017
README.md ARUHA-2687 Checked that ./gradlew clean build fullAcceptanceTest is w… Jan 23, 2020
SECURITY.md Update SECURITY.md Oct 7, 2019
build.gradle Revert "Revert "Update Kafka Clients to 2.3.0"" Feb 24, 2020
checkstyle.xml ARUHA-534 Refactor subscription api to use different streamer Apr 19, 2017
delivery.yaml ARUHA-2687 Remove failfast Jan 23, 2020
docker-compose.yml Fix for issue 1174: Align docker compose with application configuration Mar 8, 2020
gradlew Upgrade gradle to 4.8.1 Jun 22, 2018
gradlew.bat Upgrade gradle to 4.8.1 Jun 22, 2018
settings.gradle acceptance tests Jan 10, 2020

README.md

Nakadi Event Broker

Build Status codecov.io Codacy Badge

Nakadi is a distributed event bus broker that implements a RESTful API abstraction on top of Kafka-like queues, which can be used to send, receive, and analyze streaming data in real time, in a reliable and highly available manner.

One of the most prominent use cases of Nakadi is to decouple micro-services by building data streams between producers and consumers.

Main users of nakadi are developers and analysts. Nakadi provides features like REST based integration, multi consumer, ordered delivery, interactive UI, fully managed, security, ensuring data quality, abstraction of big data technology, and push model based consumption.

Nakadi is in active developement and is currently in production inside Zalando as the backbone of our microservices sending millions of events daily with a throughput of more than hundreds gigabytes per second. In one line, Nakadi is a high-scalability data-stream for enterprise engineering teams.

Nakadi Deployment Diagram

More detailed information can be found on our website.

Project goal

The goal of Nakadi (ნაკადი means stream in Georgian) is to provide an event broker infrastructure to:

  • Abstract event delivery via a secured RESTful API.

    This allows microservices teams to maintain service boundaries, and not directly depend on any specific message broker technology. Access can be managed individually for every queue and secured using OAuth and custom authorization plugins.

  • Enable convenient development of event-driven applications and asynchronous microservices.

    Event types can be defined with Event type schemas and managed via a registry. All events will be validated against the schema before publishing. This guarantees data quality and consistency for consumers.

  • Efficient low latency event delivery.

    Once a publisher sends an event using a simple HTTP POST, consumers can be pushed to via a streaming HTTP connection, allowing near real-time event processing. The consumer connection has keepalive controls and support for managing stream offsets using subscriptions.

Development status

  • Nakadi is high-load production ready.
  • Zalando uses Nakadi as its central Event Bus Service.
  • Nakadi reliably handles the traffic from thousands event types with the throughput of more than hundreds gigabytes per second.
  • The project is in active development.

Presentations

Features

  • Stream:
    • REST abstraction over Kafka-like queues.
    • CRUD for event types.
    • Event batch publishing.
    • Low-level interface (deprecated).
      • manual client side partition management is needed
      • no support of commits
    • High-level interface (Subscription API).
      • automatic redistribution of partitions between consuming clients
      • commits should be issued to move server-side cursors
  • Schema:
    • Schema registry.
    • Several event type categories (Undefined, Business, Data Change).
    • Several partitioning strategies (Random, Hash, User defined).
    • Event enrichment strategies.
    • Schema evolution.
    • Events validation using an event type schema.
  • Security:
    • OAuth2 authentication.
    • Per-event type authorization.
    • Blacklist of users and applications.
  • Operations:
    • STUPS platform compatible.
    • ZMON monitoring compatible.
    • SLO monitoring.
    • Timelines:
      • this allows transparently switch production and consumption to different cluster (tier, region, AZ) without moving actual data and any service degradation.
      • opens the possibility for implementation of other streaming technologies and engines besides Kafka (like Amazon Kinesis or Google Cloud Pub/Sub)

Read more about latest development on the releases page.

Additional features that we plan to cover in the future are:

  • Support for different streaming technologies and engines. Nakadi currently uses Apache Kafka as its broker, but other providers (such as Kinesis) will be possible.
  • Filtering of events for subscribing consumers.
  • Store old published events forever using transparent fall back backup shortages like AWS S3.
  • Separate the internal schema register to standalone service.
  • Use additional schema formats and protocols like Avro, protobuf and others.

Related projects

The zalando-nakadi organisation contains many useful related projects like

How to contribute to Nakadi

Read our contribution guidelines on how to submit issues and pull requests, then get Nakadi up and running locally using Docker:

Dependencies

The Nakadi server is a Java 8 Spring Boot application. It uses Kafka 1.1.1 as its broker and PostgreSQL 9.5 as its supporting database.

Nakadi requires recent versions of docker and docker-compose. In particular, docker-compose >= v1.7.0 is required. See Install Docker Compose for information on installing the most recent docker-compose version.

The project is built with Gradle. The ./gradlew wrapper script will bootstrap the right Gradle version if it's not already installed.

Install

To get the source, clone the git repository.

git clone https://github.com/zalando/nakadi.git

Building

The gradle setup is fairly standard, the main tasks are:

  • ./gradlew build: run a build and test
  • ./gradlew clean: clean down the build

Some other useful tasks are:

  • ./gradlew startNakadi: build Nakadi and start docker-compose services: nakadi, postgresql, zookeeper and kafka
  • ./gradlew stopNakadi: shutdown docker-compose services
  • ./gradlew startStorages: start docker-compose services: postgres, zookeeper and kafka (useful for development purposes)
  • ./gradlew stopStorages: shutdown docker-compose services
  • ./gradlew fullAcceptanceTest: start Nakadi configured for acceptance tests and run acceptance tests

For working with an IDE, the eclipse IDE task is available and you'll be able to import the build.gradle into Intellij IDEA directly.

Running a Server

From the project's home directory you can start Nakadi via Gradle:

./gradlew startNakadi

This will build the project and run docker compose with 4 services:

  • Nakadi (8080)
  • PostgreSQL (5432)
  • Kafka (9092)
  • Zookeeper (2181)

To stop the running Nakadi server:

./gradlew stopNakadi

Using Nakadi and its API

Please read the manual for the full API usage details.

Creating Event Types

The Nakadi API allows the publishing and consuming of events over HTTP. To do this the producer must register an event type with the Nakadi schema registry.

This example shows a minimalistic undefined category event type with a wildcard schema:

curl -v -XPOST http://localhost:8080/event-types -H "Content-type: application/json" -d '{
  "name": "order.ORDER_RECEIVED",
  "owning_application": "order-service",
  "category": "undefined",
  "schema": {
    "type": "json_schema",
    "schema": "{ \"additionalProperties\": true }"
  }
}'

Note: This is not a recommended category and schema. It should be used only for testing.

You can read more about this in the manual.

Consuming Events

You can open a stream for an event type via the events sub-resource:

curl -v http://localhost:8080/event-types/order.ORDER_RECEIVED/events


HTTP/1.1 200 OK

{"cursor":{"partition":"0","offset":"82376-000087231"},"events":[{"order_number": "ORDER_001"}]}
{"cursor":{"partition":"0","offset":"82376-000087232"}}
{"cursor":{"partition":"0","offset":"82376-000087232"},"events":[{"order_number": "ORDER_002"}]}
{"cursor":{"partition":"0","offset":"82376-000087233"},"events":[{"order_number": "ORDER_003"}]}

You will see the events when you publish them from another console for example. The records without events field are Keep Alive messages.

Note: the low-level API should be used only for debugging. It is not recommended for production systems. For production systems, please use the Subscriptions API.

Publishing Events

Events for an event type can be published by posting to its "events" collection:

curl -v -XPOST http://localhost:8080/event-types/order.ORDER_RECEIVED/events \
 -H "Content-type: application/json" \
 -d '[{
    "order_number": "24873243241"
  }, {
    "order_number": "24873243242"
  }]'


HTTP/1.1 200 OK  

Read more in the manual.

Contributing

Nakadi accepts contributions from the open-source community.

Please read CONTRIBUTING.md.

Please also note our CODE_OF_CONDUCT.md.

Contact

This email address serves as the main contact address for this project.

Bug reports and feature requests are more likely to be addressed if posted as issues here on GitHub.

License

Please read the full LICENSE

The MIT License (MIT) Copyright © 2015 Zalando SE, https://tech.zalando.com

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

You can’t perform that action at this time.