JUST EAT, AWS and a Message Bus

We’ve recently embraced Event Driven Architecture as a cornerstone for a decent chunk of our platform. This post introduces our latest open source library which is a super simple, easy to use Message Bus built on top of AWS. In later posts I’ll cover the motivations and benefits of our decision and some more in-depth first hand experience of our journey. So, for now…

Introducing “JustSaying“…


What is it?

JustSaying is a c# library giving very easy to use Message Bus type functionality on top of Amazon’s SNS and SQS services.

We’ve taken inspiration from the likes of Greg Young, MassTransit, NServiceBus et al. Ultimately we’ve come up with a simplistic, robust AWS centric way of getting messages published and consumed across component boundaries without the need to host any additional infrastructure.

We’ve put a lot of focus on the following:

  • Fluent, readable, extensible configuration syntax
  • Developer friendliness
  • Minimal configuration
  • Un-intrusive extension of existing/legacy codebases


Yeah Yeah…whatever – just show me the snippets…

Publishing a message:


Consuming a message


More advanced? Hit the read-me on GitHub: //github.com/justeat/JustSaying


How does it work?

SNS as an exchange.

SQS as a delivery mechanism.

Enough said?


Why we built it

  1. One of the main things we were missing in JUST EAT’s platform until recently was a structured way to represent State Change across our services, causing us some difficulties in API design and working with our legacy components.
  2. We wanted a more robust system in place for dealing with outages, which resulted in less service interruption and data loss… Hey, we’re in The Cloud – instances go missing! 
  3. It isn’t an easy job to wire together the Amazon services; discovery can be an issue. A tool to make this easy was the only option in a multi (independent) team environment.
  4. Due to the above, we have been running it internally in an OpenSource fashion for some time.
  5. Using SNS and SQS together is extremely cost-effective and reliable.


 A voyage of discovery

We’ve taken a highly agile approach of only build what you need, and so the current state of the library is a direct reflection of our problem space. Here’s a (by no means exclusive) list of the features we needed and have built in:

  • Throttling consumers
  • Delayed message delivery
  • Configurable publish and consume retry attempts
  • Monitoring of key metrics
  • Extensible subscription and publishing configuration (for example delivery one per instance for load balanced components)
  • Guaranteed only once delivery
  • Strongly typed message delivery
  • Configurable serialisation strategy
  • Dead letter queues (for failed message handling)


Blog posts on some of these detailed topics to come.



Source code is available on GitHub here:

NuGet packages available here: