NATS: A Cloud Native
Messaging System
Shiju Varghese
https://medium.com/@shijuvar
DevConf.IN
05 August 2018
Bengaluru
About Me
• Solutions Architect and Go Developer

• Consulting Architect and Trainer on Go and Cloud-Native architectures 

• Published Author of two books on Go

• Awarded Microsoft MVP seven times

• Speaker at numerous conferences

• medium.com/@shijuvar | github.com/shijuvar | linkedin.com/in/shijuvar
Agenda
• Understand the practical challenges in distributed systems and
microservices

• Introduction to NATS and NATS Streaming server

• Demo: Building event-driven microservices with NATS Streaming server
Cloud-Native Distributed Systems Architectures
Microservices Architecture
• Composed	of	a	suite	of	small	services	
• Each	service	runs	in	its	own	process	
• Greater	flexibility	for	scalability
Microservices Architecture
Product
Catalog
Service
Customer
Service
Order
Service
Payment
Service
Product
Catalog
Database
Customer
Database
Order
Database
Payment
Database
API
Gateway
Browser
Client
Mobile
Client
REST
REST
Product
Catalog
Service
Customer
Service
Order
Service
Payment
Service
Product
Catalog
Database
Customer
Database
Order
Database
Payment
Database
• Single-purpose, domain model based on
bounded context
• Database per service, Isolated persistence
• A transaction (a command on an aggregate)
may span into multiple microservices
• Distributed transactions with 2PC is not
viable option
• How to manage failures while performing
distributed transactions
• How to manage data consistency
• How to querying data from multiple data
store
Challenges / Considerations
Event-Driven Approach
Payment
Service
Order
Service
Order
Database
Publish Events
Message
Broker
Publish Events
Subscribe Events
Subscribe Events
Event: OrderCreated
Restaurant
Service
Publish Events
Subscribe Events
Event: PaymentDebitedEvent: OrderApproved
Cloud-Native Messaging with NATS
• A Cloud Native Computing Foundation (CNCF) hosted incubation project
• NATS is an open-source, high performant cloud-native messaging system
• Available in two modules: NATS server (gnatsd) and NATS Streaming (nats-
streaming-server)
• The basic NATS server is capable of sending 18 million messages per second
• Both NATS and NSTS Streaming Server are written in Go
• NATS was created by Derek Collison, and supported and maintained by his
team at Synadia Communications
A Nervous System for Microservices and Distributed Systems
NATS In Production
Messaging Architecture
• Messages: The unit of data exchange
• Subject: Specify the destination of the message
• Producers: Send messages to the server under a specific subject
• Consumers: Subscribe to receive messages matching a
subscription
• Messaging Server: Distributes messages from producers to
consumers
NATS Server
• Highly performant, extremely light-weight
• Clustered servers/cluster-aware clients
• Built-in resiliency and high availability
• Text-based protocol (payload is an array of bytes)
• Monitorable on a dedicated port - returning JSON data describing
the state of the server
Chart source: http://bravenewgeek.com/dissecting-message-queues/
Client APIs
Messaging Patterns
• Publish-Subscribe
• Queueing
• Request-Replay
Publish-Subscribe
• Basic messaging pattern
• A producer publishes a message with a specific subject
• All active consumers with subscriptions matching the subject receive it
Pub Sub
Queueing
• It’s a publish-subscribe operation
• Consumers subscribe using a shared queue group name
• A publisher sends a message
• The messaging server forwards to single subscriber
• Non members of the queue group will get message as standard pub-sub
• Multiple queue group names subscribers on the same subject are possible
Queuing
Request-Reply
• Producer creates a subscription to an unique subject name (a.k.a. reply subject)
• The producer publishes a message with the reply subject
• Subscribers receive the message and publish a response to the reply subject
• Very efficient 1:1 of very large N
Request Reply
Pub/Sub Demo
NATS Streaming Server
NATS Streaming is an extremely performant,
lightweight reliable streaming platform built on NATS
that provides an API for persistent logs.
NATS Streaming Server
• Message/event persistence: Memory, File, SQL Databases
• At-least-once-delivery
• Publisher rate limiting
• Rate matching/limiting per subscriber
• Historical message replay by subject
• Durable subscriptions
Channels
• Channels are subject clients that send data to and consume from
• It does not support wildcard for channels
• Messages published to a channel are stored in a message log
inside the channel
Message Log
• Messages that published to a channel are appended to the end of
the log in the persistent store
• By default, NATS Streaming uses an in-memory store for the
messages
• FILE and SQL can be used for persistent store by configuring the --
store option.
•
Running NATS Streaming Server
nats-streaming-server 
--store file 
--dir ./data 
--max_msgs 0 
--max_bytes 0
--store <string> Store type: MEMORY|FILE|SQL (default: MEMORY)
--dir <string> For FILE store type, this is the root directory
--max_msgs <int> Max number of messages per channel (0 for unlimited)
--max_bytes <size> Max messages total size per channel (0 for unlimited)
NATS Streaming Subscriptions
• Regular
• Durable
• Queue Group
• Redelivery
Demo: Building Event-Driven Microservices with
NATS Streaming Server
Query Model Sync with NATS QueueGroup
Client App
Order Service
REST API
Event Store
gRPC Server
NATS ProducerProtoBuf
Command -CockroachDB
Cluster
Node 1 Node 2 Node N
Events
NATS Streaming
Server
Message Logs
Restaurant
Service
NATS Consumer
Query Store -1
NATS Consumer
Query Store -2
NATS Consumer
Query -CockroachDB
Cluster
Node 1 Node 2 Node N
Technology:
• Go
• gRPC
• NATS Streaming
• CockroachDB
Example Events:
• OrderCreated
• PaymentDebited
• OrderApproved
• OrderRejected
• OrderShipped
• OrderDelivered
Payment Service
NATS Consumer
https://github.com/shijuvar/go-distributed-sys
1. A client app post an Order to an HTTP API.
2. An HTTP API receives the order, then executes a command onto Event Store (an immutable log of
events) to create an event via its gRPC API.
3. The Event Store API executes the command and then publishes an event "order-created" to NATS
Streaming server to let other services know that an event is created.
4. The Payment service subscribes the event “order-created”, then make the payment, and then
create an another event “order-payment-debited” via Event Store API.
5. The Query models are also subscribing the event “order-created” that synchronise the data models
to provide state of the aggregates for query views.
6. The Event Store API executes a command onto Event Store to create an event “order-payment-
debited” and publishes an event to NATS Streaming server to let other services know that the
payment has been debited.
7. The restaurant service finally approves the order.
8. A Saga coordinator manages the distributed transactions and makes void transactions on failures.
Thanks
Shiju Varghese
gophermonk@gmail.com
https://medium.com/@shijuvar
https://github.com/shijuvar
https://linkedin.com/in/shijuvar
Go Programming Workshops: https://github.com/shijuvar/gokit/tree/master/training/README.md

NATS: A Cloud Native Messaging System

  • 1.
    NATS: A CloudNative Messaging System Shiju Varghese https://medium.com/@shijuvar DevConf.IN 05 August 2018 Bengaluru
  • 2.
    About Me • SolutionsArchitect and Go Developer • Consulting Architect and Trainer on Go and Cloud-Native architectures • Published Author of two books on Go • Awarded Microsoft MVP seven times • Speaker at numerous conferences • medium.com/@shijuvar | github.com/shijuvar | linkedin.com/in/shijuvar
  • 3.
    Agenda • Understand thepractical challenges in distributed systems and microservices • Introduction to NATS and NATS Streaming server • Demo: Building event-driven microservices with NATS Streaming server
  • 4.
  • 5.
    Microservices Architecture • Composed of a suite of small services •Each service runs in its own process • Greater flexibility for scalability
  • 6.
  • 7.
    Product Catalog Service Customer Service Order Service Payment Service Product Catalog Database Customer Database Order Database Payment Database • Single-purpose, domainmodel based on bounded context • Database per service, Isolated persistence • A transaction (a command on an aggregate) may span into multiple microservices • Distributed transactions with 2PC is not viable option • How to manage failures while performing distributed transactions • How to manage data consistency • How to querying data from multiple data store Challenges / Considerations
  • 8.
    Event-Driven Approach Payment Service Order Service Order Database Publish Events Message Broker PublishEvents Subscribe Events Subscribe Events Event: OrderCreated Restaurant Service Publish Events Subscribe Events Event: PaymentDebitedEvent: OrderApproved
  • 9.
  • 10.
    • A CloudNative Computing Foundation (CNCF) hosted incubation project • NATS is an open-source, high performant cloud-native messaging system • Available in two modules: NATS server (gnatsd) and NATS Streaming (nats- streaming-server) • The basic NATS server is capable of sending 18 million messages per second • Both NATS and NSTS Streaming Server are written in Go • NATS was created by Derek Collison, and supported and maintained by his team at Synadia Communications A Nervous System for Microservices and Distributed Systems
  • 11.
  • 12.
    Messaging Architecture • Messages:The unit of data exchange • Subject: Specify the destination of the message • Producers: Send messages to the server under a specific subject • Consumers: Subscribe to receive messages matching a subscription • Messaging Server: Distributes messages from producers to consumers
  • 13.
    NATS Server • Highlyperformant, extremely light-weight • Clustered servers/cluster-aware clients • Built-in resiliency and high availability • Text-based protocol (payload is an array of bytes) • Monitorable on a dedicated port - returning JSON data describing the state of the server
  • 14.
  • 15.
  • 16.
  • 17.
    Publish-Subscribe • Basic messagingpattern • A producer publishes a message with a specific subject • All active consumers with subscriptions matching the subject receive it
  • 18.
  • 19.
    Queueing • It’s apublish-subscribe operation • Consumers subscribe using a shared queue group name • A publisher sends a message • The messaging server forwards to single subscriber • Non members of the queue group will get message as standard pub-sub • Multiple queue group names subscribers on the same subject are possible
  • 20.
  • 21.
    Request-Reply • Producer createsa subscription to an unique subject name (a.k.a. reply subject) • The producer publishes a message with the reply subject • Subscribers receive the message and publish a response to the reply subject • Very efficient 1:1 of very large N
  • 22.
  • 23.
  • 24.
  • 25.
    NATS Streaming isan extremely performant, lightweight reliable streaming platform built on NATS that provides an API for persistent logs.
  • 26.
  • 27.
    • Message/event persistence:Memory, File, SQL Databases • At-least-once-delivery • Publisher rate limiting • Rate matching/limiting per subscriber • Historical message replay by subject • Durable subscriptions
  • 28.
    Channels • Channels aresubject clients that send data to and consume from • It does not support wildcard for channels • Messages published to a channel are stored in a message log inside the channel
  • 29.
    Message Log • Messagesthat published to a channel are appended to the end of the log in the persistent store • By default, NATS Streaming uses an in-memory store for the messages • FILE and SQL can be used for persistent store by configuring the -- store option. •
  • 30.
    Running NATS StreamingServer nats-streaming-server --store file --dir ./data --max_msgs 0 --max_bytes 0 --store <string> Store type: MEMORY|FILE|SQL (default: MEMORY) --dir <string> For FILE store type, this is the root directory --max_msgs <int> Max number of messages per channel (0 for unlimited) --max_bytes <size> Max messages total size per channel (0 for unlimited)
  • 31.
    NATS Streaming Subscriptions •Regular • Durable • Queue Group • Redelivery
  • 32.
    Demo: Building Event-DrivenMicroservices with NATS Streaming Server
  • 33.
    Query Model Syncwith NATS QueueGroup Client App Order Service REST API Event Store gRPC Server NATS ProducerProtoBuf Command -CockroachDB Cluster Node 1 Node 2 Node N Events NATS Streaming Server Message Logs Restaurant Service NATS Consumer Query Store -1 NATS Consumer Query Store -2 NATS Consumer Query -CockroachDB Cluster Node 1 Node 2 Node N Technology: • Go • gRPC • NATS Streaming • CockroachDB Example Events: • OrderCreated • PaymentDebited • OrderApproved • OrderRejected • OrderShipped • OrderDelivered Payment Service NATS Consumer https://github.com/shijuvar/go-distributed-sys
  • 34.
    1. A clientapp post an Order to an HTTP API. 2. An HTTP API receives the order, then executes a command onto Event Store (an immutable log of events) to create an event via its gRPC API. 3. The Event Store API executes the command and then publishes an event "order-created" to NATS Streaming server to let other services know that an event is created. 4. The Payment service subscribes the event “order-created”, then make the payment, and then create an another event “order-payment-debited” via Event Store API. 5. The Query models are also subscribing the event “order-created” that synchronise the data models to provide state of the aggregates for query views. 6. The Event Store API executes a command onto Event Store to create an event “order-payment- debited” and publishes an event to NATS Streaming server to let other services know that the payment has been debited. 7. The restaurant service finally approves the order. 8. A Saga coordinator manages the distributed transactions and makes void transactions on failures.
  • 35.