Building event-driven applications the easy way in Go.
Alternatives To Watermill
Project NameStarsDownloadsRepos Using ThisPackages Using ThisMost Recent CommitTotal ReleasesLatest ReleaseOpen IssuesLicenseLanguage
Hoppscotch54,8042a day ago9February 07, 2023184mitTypeScript
👽 Open source API development ecosystem - https://hoppscotch.io
Locust22,1873569a day ago247July 25, 202320mitPython
Write scalable load tests in plain Python 🚗💨
Vert.x13,7677,633658a day ago136June 22, 2023283otherJava
Vert.x is a tool-kit for building reactive applications on the JVM
Httpbin11,9275496a month ago13May 08, 2018179iscPython
HTTP Request & Response Service, written in Python + Flask.
Pollyjs9,964431268 days ago47July 20, 202337apache-2.0JavaScript
Record, Replay, and Stub HTTP Interactions.
Gopher Reading List7,693
18 days ago7apache-2.0
A curated selection of blog posts on Go
Artillery6,95217170a day ago173August 04, 2023403mpl-2.0JavaScript
Load testing at cloud-scale, as easy as 1-2-3. Serverless & distributed out-of-the-box. Never fail to scale!
Rest Assured6,5157,3644813 days ago32June 16, 2023527apache-2.0Java
Java DSL for easy testing of REST services
Hurl6,231219 hours ago14June 30, 2023111apache-2.0Rust
Hurl, run and test HTTP requests with plain text.
Watermill6,0931822 days ago45July 16, 202384mitGo
Building event-driven applications the easy way in Go.
Alternatives To Watermill
Select To Compare

Alternative Project Comparisons


CI Status Go Reference Go Report Card codecov

Watermill is a Go library for working efficiently with message streams. It is intended for building event driven applications, enabling event sourcing, RPC over messages, sagas and basically whatever else comes to your mind. You can use conventional pub/sub implementations like Kafka or RabbitMQ, but also HTTP or MySQL binlog if that fits your use case.


  • Easy to understand.
  • Universal - event-driven architecture, messaging, stream processing, CQRS - use it for whatever you need.
  • Fast (see Benchmarks).
  • Flexible with middlewares, plugins and Pub/Sub configurations.
  • Resilient - using proven technologies and passing stress tests (see Stability).

Getting Started

Pick what you like the best or see in order:

  1. Follow the Getting Started guide.
  2. See examples below.
  3. Read the full documentation: https://watermill.io/

Our online hands-on training



Building distributed and scalable services is rarely as easy as some may suggest. There is a lot of hidden knowledge that comes with writing such systems. Just like you don't need to know the whole TCP stack to create a HTTP REST server, you shouldn't need to study all of this knowledge to start with building message-driven applications.

Watermill's goal is to make communication with messages as easy to use as HTTP routers. It provides the tools needed to begin working with event-driven architecture and allows you to learn the details on the go.

At the heart of Watermill there is one simple interface:

func(*Message) ([]*Message, error)

Your handler receives a message and decides whether to publish new message(s) or return an error. What happens next is up to the middlewares you've chosen.

You can find more about our motivations in our Introducing Watermill blog post.


All publishers and subscribers have to implement an interface:

type Publisher interface {
	Publish(topic string, messages ...*Message) error
	Close() error

type Subscriber interface {
	Subscribe(ctx context.Context, topic string) (<-chan *Message, error)
	Close() error

Supported Pub/Subs:

All Pub/Subs implementation documentation can be found in the documentation.

Unofficial libraries

Can't find your favorite Pub/Sub or library integration? Check Awesome Watermill.

If you know another library or are an author of one, please add it to the list.


Please check our contributing guide.


Watermill v1.0.0 has been released and is production-ready. The public API is stable and will not change without changing the major version.

To ensure that all Pub/Subs are stable and safe to use in production, we created a set of tests that need to pass for each of the implementations before merging to master. All tests are also executed in stress mode - that means that we are running all the tests 20x in parallel.

All tests are run with the race condition detector enabled (-race flag in tests).

For more information about debugging tests, you should check tests troubleshooting guide.


Initial tools for benchmarking Pub/Subs can be found in watermill-benchmark.

All benchmarks are being done on a single 16 CPU VM instance, running one binary and dependencies in Docker Compose.

These numbers are meant to serve as a rough estimate of how fast messages can be processed by different Pub/Subs. Keep in mind that the results can be vastly different, depending on the setup and configuration (both much lower and higher).

Here's the short version for message size of 16 bytes.

Pub/Sub Publish (messages / s) Subscribe (messages / s)
GoChannel 331,882 118,943
Redis Streams 61,642 11,213
NATS Jetstream (16 Subscribers) 49,255 33,009
Kafka (one node) 44,090 108,285
SQL (MySQL) 5,599 167
SQL (PostgreSQL, batch size=1) 3,834 455
Google Cloud Pub/Sub 3,689 30,229
AMQP 2,702 13,192


If you didn't find the answer to your question in the documentation, feel free to ask us directly!

Please join us on the #watermill channel on the Three Dots Labs Discord.

Every bit of feedback is very welcome and appreciated. Please submit it using the survey.

Why the name?

It processes streams!


MIT License

Popular Testing Projects
Popular Http Projects
Popular Software Quality Categories
Related Searches

Get A Weekly Email With Trending Projects For These Categories
No Spam. Unsubscribe easily at any time.
Event Sourcing
Event Driven
Stream Processing