I think "glue systems" can be generalized by saying: systems that consolidate events, and react to events in real-time. Most everything that happens in your system is an event, and things need to react to this. For example:
- A glue system will almost certainly plumb stripe events info a billing system, plus other systems for things like failed payments.
This system shouldn't go down (HA). It should be able to react to changes easily - as biz ops change frequently. It should be auditable, easy to debug, and easy to deploy.
The first pass at this in startups is usually... just doing stuff in the API request, or building webhook endpoints that manage this for you within the API. Then, you might add Sidekiq, or SQS/Lambda. Then, you might build out event-driven architecture using SQS/Kafka. It's kind of a pain, and still it's not easy to grok, debug, or architect.
Inngest handles all of this for you, though. It consolidates events from every system (internal and external, via APIs, webhooks, oauth, etc.) and then allows you to run DAG-based workflows in real-time whenever events are received. With full logging, debugging (step-over debugging), retries, user-auditing, changelogs, version control, etc.
I think that event-driven systems and glue-based systems overall haven't had much love in the developer UX, but I'm hopeful we can change that. If you're interested in using us or working with us on building the platform, ping me :)