SD/TL: Message Queues and Ticketing Systems
Asynchronous handling of work which would overload a system if performed synchronously
This is a post in my “system design applied to tech leadership” series.
In this series I compare elements of tech leadership with elements of system design.
*
In system design, a queue can take load off of one part of the system and distribute that load asynchronously to other parts of the system.
Consider the publisher/subscriber [pub/sub] model: a publisher publishes and message and, at the other end of the queue, a subscriber does something in response to that message.
A classic example is simultaneously recording an order in a database while publishing a message about the order in a queue. At the other end of the queue, a subscriber consumes the message, then sends out a notification to the buyer that the order has been processed. This decouples notification from the critical work of saving the order, taking stress off of the order save part of the system. It works because the notification can be processed asynchronously, eventually, by a consumer notification process.
Add in scaling, which allows you to expand or shrink the number of notification consumers, and you have a system which saves orders at order time and notifies as quickly as possibly based on how many notification consumers can be spun up to consume order messages from the queue.
A canonical queueing mechanism is Apache Kafka.
*
The same concept holds true for ticketing in tech leadership.
In the near-term future, some firms are promising that a mystical being, Kellum, will deliver synchronous technological results to business requests.
That future does not exist, so there is still a lag between request and delivery.
A ticketing system fills that asynchronous lag.
Like the system design queue, the ticketing system reduces load from one part of the system [the requestor] while distributing that load asynchronously to other parts of the organization [the delivery team].
Like the system design queue, the ticketing system can benefit from scaling. Having a team of 2 delivery folks to consume 10 tickets per week might be sufficient. But scale that to 100 tickets per week, and you’ll need to scale your delivery team. The ticketing system works the same for both: it maintains a queue of tickets, called a backlog, for delivery folks to consume and address.
A canonical ticketing system is Jira.