Maestro Planned Tasks
Today, I worked quite a lot on Maestro.
Maestro is a language agnostic task scheduler written in Golang. It is fast, stateless and battle tested in production in my company since several months.
Maestro differentiates itself from classical task queues in different forms :
- Tasks put in a maestro queue have an owner. This owner is used to reorder the queue in real time in a “fair way” for each owner.
- Tasks have a running timeout
- Tasks have can be retried
- Executed tasks can have a result
- It is possible to follow the state of a task individually (without consuming the whole result queue)
- Each task queue have a result queue that can be consumed as a normal queue
- Tasks can be planned to be executed in the future
- When done, a task (and its result) is automatically deleted after a given time (or manually).
My today’s work added these features to Maestro :
- The healthcheck now checks the Redis connection
- Tasks can be planned to be performed in the future (creating the base system for recurring tasks)
- It is possible to inspect the tasks states in a queue
- A prometheus metrics endpoint have been added that returns the number of task that flowed to their different states
I quite happy with this work. Maestro really became a base building block of the distributed system built at my company. These new features will allow us to simplify the way we manage recurring tasks and their interlocking between multiple instances of our applications (maestro will become a synchronization mechanism). More over, other today’s adds will enhance observability and stability of Maestro.
In a near future, I should probably write/update the documentation of the project on Github and expose it a little bit more (on Hackernews or something). Moreover, test coverture should be improved on certain parts of the app, especially the inner queue task scheduling code.