Skip to content
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Go to file
Cannot retrieve contributors at this time



Scalable web services using message queues with Msgflo and GuvScale

Different parts of your application have different performance characteristics. Some tasks are CPU-bound, some database-limited, some limited by external APIs/services. By splitting tasks out to dedicated workers using a message queues like RabbitMQ we can scale each worker role independently. This can enable a higher overall application performance and cost-efficiency. I'll show how MsgFlo tooling makes it easier to set up and understand a distributed, multi-worker system. And then how to automatically scale the workers based on their amount of tasks, using the GuvScale Heroku addon.



Slides, with a demo split over two sections/sessions.


The problem: Building a performant, cost-effective cloud service that is scalable. Solution: Use MsgFlo to separate work into dedicated workers communicating over RabbitMQ. Use GuvScale to automatically scale the different workers according to their loads.


10 minutes.

  • whoami
  • This talk.
  • @TheGrid. Content analysis, constraint solving, image processing.
  • Distributed system. Definition, characteristics.
  • Example problem/system
  • What to split to background workers. "A good rule of thumb is to avoid web requests which run longer than 500ms".
  • ? Different communication approaches
  • How AMQP/RabbitMQ works
  • Why message queues/broker. Persistence/retry/resume


10 minutes.

Live demo

10 minutes.

  • Live service existing on Heroku. What was needed to put it there
  • Testing with some example data
  • Showing the code, participants
  • Killing the worker, processing resumes when up again.
  • Overwhelming the service with requests, performance degrades.

QA: Msgflo

5-10 minutes


10 minutes

QA: GuvScale

5-10 minutes


  • Msgflo best practices
  • GuvScale best practices
  • Common architecture patterns. Syncronous request/response. Different processors, then combine results. Routing for quality of service. Autonomous system isolated from frontend/web. Process control etc
  • Flowhub. Visually. Can instrospect and live-program
  • Summarize each main section, key points
  • Summarize everything at the end


Key points

  • Use message queues for distributed systems, instead of request/response like HTTP
  • Using hetrogenous workers enables more efficient scaling, compared to homogenous all-in-frontend Each worker has known perf bounds. Can operate very close to RAM limits. 100% utilization good not bad!
  • Flowhub w/Msgflo makes it easier to understand the system. Lifting the queue connections up, out of individual code. Visualizing your live architecture.
  • Use GuvScale on Heroku for autoscaling your system. Maintain a predictable performance. Keep 90+% utilization.


  • Making the external HTTP API async allows more flexibility in scaling. create-job:response...request:status/results
  • Job APIs should generally take sets (N), not invididual items, as input. Less requests, can keep closer to client model.


  • Writing tests black-box. Can run against production/staging service. Ensures introspectabilty from outside.
  • Storing jobs with timestamps and results/errors, lets you query it later. Debugging. Can replace analytics services.

Calls to action

  • Go to the GuvScale website. Install the beta for your Heroku system.
  • Try out the Msgflo example app.
  • Go to website. Make your next service based on message-queues with Msgflo.
  • Come talk to me afterwards. About message queues, data-driven programming, autoscaling

Not covered

Maybe just mention in brief

  • MsgFlo for IoT / embedded device networks
  • General-purpose programming with Flowhub (NoFlo/MicroFlo).



sequence diagram.

RabbitMQ logo

Constraint solving graph

TheGrid content analysis

Image processing


How broker model work

# DSL used:
title: Broker model

participant web
participant worker
participant otherworker
participant RabbitMQ

web->RabbitMQ: Job {}
RabbitMQ->worker: Job {}
worker->RabbitMQ: JobResult {}
RabbitMQ->otherworker: JobResult {}
# DSL used:
title: Direct model

participant web
participant worker
participant otherworker

web->worker: Job {}
worker->otherworker: JobResult {}


Complete demo app.


msgflo-nodejs, AMQP/RabbitMQ backend

  • Support edge data instrospection
  • Support/test live-changes to data-routing