The document presents a webinar on using NATS for messaging and microservices, covering messaging basics, architecture, consumer-producer interactions, and messaging patterns. It outlines key features like scalability, fault tolerance, and service discovery within a messaging system, illustrated through a case study involving a large-scale application like Pokémon Go. The presentation emphasizes the advantages of message-driven microservices in building scalable and manageable applications adaptable to change.

1. NATS for Modern Messaging and
Microservices
Presented by Alberto Ricart, Principal Engineer, NATS

2. •Community and Ecosystem Manager, NATS.io
• Ways to get involved in NATS Community:
- http://nats.io/community/
Brian Flannery
@brianflannery
brian.flannery@apcera.com

3. •Principal Engineer at Apcera
•Previously with
- TIBCO > 15 years
- Informatica
•Building messaging based systems > 20 years
Alberto Ricart
@alberto.ricart
alberto.ricart@apcera.com

4. - Learn/review messaging basics
- Use messaging patterns
- Describe a sample microservices application
‣ See how NATS and messaging features help us make our services better
What this webinar will cover

5. Part 1: Messaging Basics

6. ๏ Messages - are the unit of data exchange
๏ Producers - send messages to the server
๏ Consumers - receive messages from the server
๏ Messaging Server - distributes messages from producers to consumers
Messaging architecture

7. ๏Have a subject that describes the message contents
๏A payload
{location: {lat: 45.678, lng: 123.456}}
Messages

8. ๏Subject names are extremely important
‣ They specify the destination of the message
Pokenats.eden-service.12.hb.1234
๏They consist of one or more elements (tokens) separated by dots
‣ The elements can be used to create a subject name hierarchies
‣ Individual elements can be thought of as metadata which a service could use
while processing the message
What’s in a subject?

9. ๏Send messages to the server under a specific subject - ‘publishers’
๏Don’t assume the audience of the message
‣ Don’t care who consumes the message
๏A publisher may specify an optional “reply” subject to change the meaning of the
message
Producers

10. ๏ Subscribe to receive messages matching a subscription
๏ Can specify a queue group name
‣ Single member of a queue group is chosen randomly to receive the message
๏ Can specify how many messages to receive before auto-canceling
• This is a big deal
Consumers

11. ๏ Subscribers can specify wildcards
pokenats.eden-service.>
pokenats.*.*.hb.100
๏ ‘*’ matches any value in that element
๏ ‘>’ matches all elements that follow
‣ ‘>’ is only valid at the end of the subject
Subscription wildcards

12. ๏ 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)
‣ Use telnet to explore
๏ Monitorable on a dedicated port - returning JSON data describing the state of the
server
NATS server features
Chart source: http://bravenewgeek.com/dissecting-
message-queues/

13. ๏ Server protects itself first
‣ Auto-pruning of slow/non-responsive clients
‣ Disconnects clients that send bad protocol messages
๏ At most once delivery
๏ Client APIs for many languages
‣ Community contributed: Spring, Lua, PHP, Python, Scala, Haskel, C#
MyNatsClient
‣ Easy to develop a client. Get involved!
NATS server features (Cont.)

14. ๏ Provides additional features, built on top of NATS
‣ Clients publish to a streaming server
‣ Messages stored until number or size limits are reached
‣ Subscribers can request messages sent earlier
• Start with first/last/n-th/etc message
‣ Durable subscriptions
• Resume previous session
‣ At least once delivery
NATS streaming

15. Part 2: Messaging Patterns

16. - Publish-Subscribe
- Queueing
- Request-Reply
Three simple patterns

17. ๏ Basic messaging pattern
‣ A producer publishes a message with a
specific subject
‣ All active consumers with subscriptions
matching the subject receive it
Publish-Subscribe 1-N

18. ๏ 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
Queueing 1-1
(Subscribers using a shared queue group name)

19. ๏ Producer creates a subscription to an
unique subject name (a.k.a. reply subject)
‣ Sets max number of messages to
receive
๏ 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 1-N

20. ๏ Similar as before, but this time subscribers are
part of a queue group name
‣ Only one subscriber will get the request
Request Reply 1:1

21. ๏ You can build massively scalable services, and achieve many features which would
require a lot effort otherwise
‣ Addressing
‣ Discovery
‣ Control plane
‣ Load balancing
‣ Fault-tolerance
‣ Location transparency
With these simple messaging patterns

22. ๏ Use messaging for inter-service communication
‣ pub/sub, queuing, request/reply
๏ Broadcast heartbeats and health information
๏ Use control plane services to listen to service heartbeats
‣ Add, grow, shrink service queues based on health
๏ Adapt data exchanged by services
‣ Reduce integration points from 1 to N-1 to N
Microservices + messaging

23. Case Study: PokéNATS
Presented by Alberto Ricart, Principal Engineer, NATS
Small study describing how to a create simple and
highly scalable service with NATS messaging

24. Let’s put to work what we have learned...
• Design a small service oriented application
• Could have millions of users?
• Will release as a minimum viable product (many features tbd)
• How would you develop it?
- If you made it with HTTP and REST services would it scale?
- How would you manage it?
- How would you scale it?
- How would you cope with new features, changes and their deployment?

25. Take something seemingly simple like, Pokémon Go!
• Hugely popular augmented reality phone game that
launched in July 2016 based on Pokémon
• Players walk around and:
- Find Pokéstops near them
- Collect Pokémon pets found in the wild
- Level and evolve the pets to make them more powerful
- Battle their pets against other player’s

26. At its core
• It’s a massive sensor collector
- Operates in a very large playground
‣ Every few seconds new location information sent to one or more servers
‣ Every once in awhile, some game event happens
• One million players contributing sensor data every 5 seconds means:
‣ 12 million/min interactions just for the sensor information functionality

27. Being successful sometimes creates nightmares
•Imagine 130+ million downloads (Wikipedia number)
- A little times a lot in cloud scale is huge
- Any application is non-trivial at 1/1000 the success
‣ Performance
• Authentication
• Data persistence
• Business logic
‣ Monitoring & Management

28. PokéNATS Architecture
pokenats.s_type.id.event.grid
event: update | data | spawn | new
pokenats_admin.cmd.s_type.id
cmd: discover | kill | conf
pokenats_monitor.s_type.id.hb
pokenats_monitor.s_type.id.log.type
type: info | error | invalid

29. Scalability
•Queue group names allow load balancing of services
•Filtering on the subject name enables services to divide work (perhaps with
locality)
•Subscriptions from trainers filter updates and notifications from clients that are
not geographically near
•Request reply services could delay responding based on memory/cpu presure

30. Service Discovery
•Control service uses pokenats_admin.cmd.s_type.sid.discover required
sevices
•Missing services are spawned by the control service
•Filtering enables limiting the impact of a request based on a subject name

31. Fault-tolerance
• If more than one service, it is fault tolerant
‣Auto-heals when new services are added
• NATS can be configured in cluster mode
- Clients randomly connect to servers in the cluster to distribute connections
- Clients switch to a different server if their current connection fails
•Control service reacts to current information by adding and pruning

32. Load-balancing
•Queue groups again, help here
•HTTP/REST endpoints use a redirector or scaling strategy

33. Monitoring
•Log messages are sent under info/error monikers
•Heartbeats tell if services are alive and quantify their health
•Misbehaving clients (or attacks) are logged by re-publishing invalid requests

34. Management
•Control messages make services do something
- Update a configuration setting
- Exit
- Show itself

35. Future Changes
• Loosely coupled makes it easier
- Adding new services doesn’t affect the existing
- Easy to hot test new revs
‣Start a new service alongside the old
•If the new service is observed to work as desired, start more, stop the
old
•If the new service misbehaves, send a control command to kill it
‣By using queue subscriptions only 1/N clients are affected
‣Incremental deployments prevent embarrassing issues
•Integrating a new system?
- If data needs adapting, add a service to do translation!

36. Take-away
• Message-driven micro-services are:
- Better
- Smaller
- Highly scalable
- More manageable
- Able to cope with change and innovation
•More importantly, with careful patterns and design
- Code is usually simpler
- Robust - more resilient

37. @nats_io
http://www.nats.io
Learn More at
Thank You!