travisjeffery/jocko

Kafka implemented in Golang with built-in coordination (No ZK dep, single binary install, Cloud Native)

View on GitHub ↗Jump to charts ↓

Summary Information

Updated 7 minutes ago
Added to GitGenius on September 13th, 2026
Created on October 11th, 2016
Open Issues & Pull Requests: 64 (+0)
GitHub issues: Enabled
Number of forks: 371
Total Stargazers: 5,009 (+0)
Total Subscribers: 216 (+0)

Repository Insights (GitGenius)

Most active contributors

Sign in to see contributor activity.

Related repositories by overlapping contributors

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 1
New in 7 days: 0
Closed in 7 days: 0
Avg open age: 41 days
Stale 30+ days: 1
Stale 90+ days: 0

Recent activity

Opened in 7 days: 0
Closed in 7 days: 0
Comments in 7 days: 0
Events in 7 days: 0

Top labels

No label distribution available yet.

Most active issues this week

No issue events were indexed in the last 7 days.

Detailed Description

Jocko is a Kafka implementation in Go that provides protocol compatibility with Kafka clients while eliminating the ZooKeeper dependency through built-in coordination.

The project addresses the operational complexity of running Kafka by replacing ZooKeeper with Serf for service discovery and Raft for consensus, allowing deployment as a single binary. This approach simplifies cluster management and reduces the number of moving parts operators must maintain. Jocko implements the core Kafka protocol, meaning existing Kafka clients and services can work with it without modification. The tool also introduces more flexible retention policies, supporting percentage-based disk space allocation rather than only byte and time-based limits, and handles configuration changes when partition counts or topics are modified.

Jocko suits teams looking to run a distributed commit log service with minimal operational overhead, particularly those already invested in the Kafka ecosystem who want to reduce infrastructure complexity. The single-binary deployment model makes it attractive for cloud-native environments where simplicity and portability matter. The project is appropriate for those willing to work with an implementation still under active development, as consumer groups remain incomplete and replication is in early testing stages.

The project maintains active continuous integration and code coverage tracking. Development has progressed through implementing core producing and fetching functionality, partition consensus and distribution, topic management, and service discovery, with consumer group support currently in progress. The maintainer has documented the architectural decisions through published articles explaining the service discovery and consensus mechanisms alongside Kafka's storage internals, providing transparency into the design choices.