One of the projects I’ve been working recently has involved writing a system to communicate with a Clients pre-existing Legacy system. The system doesn’t have the ability to “talk out” but can be queried using a SOAP service.
The legacy system is:
- Slow to interact with
- Prone to crashing regularly
Here’s how we dealt with those 2 issues:
Since we don’t want to impact our end users experience the project has been set up to make use of Laravel queuing system with Redis and those queues are configured with Laravel Horizon.
When these jobs failed for whatever reason - including the clients system going down we wanted to be notified so that someone could look into what was happening.
The team at spatie.be created a great package to do that handle notifying us when a failed job occurred.
However there are multiple jobs being run concurrently that run as frequently as every minute to check for things on their server. Which mean’t that once the legacy system went down we would receive multiple notifications until the system came back up, (In some cases this has been hours - not ideal).
After a while being flooded with these sorts of notifications makes them become an annoyance rather than useful and you begin to start ignoring them.
So I set out to write something that gave me everything the Spatie package did but also allowed me to throttle how frequently notification of a given type would be sent to us.
Laravel throttled failed jobs!Continue reading