Hey everyone, I am looking for some architectural advice from anyone who has implemented high-concurrency custom endpoints or external data aggregators in Directus. We have been using Directus alongside PostgreSQL and Redis as the central backend API and content layer for an online bill tracking application similar to the setup we run on this resource, where visitors input their utility reference identifiers to fetch and review their latest monthly electricity statements.
The core challenge we are running into is that the upstream utility provider servers are notoriously unstable and slow to respond, particularly during the first two weeks of the month when billing statements are released and traffic surges dramatically. When hundreds of users simultaneously query their billing status, our custom Directus endpoint dispatches requests to the external utility gateway. If the upstream provider throttles connections or experiences socket timeouts, those pending promises pile up and exhaust the Node event loop and connection pool within Directus, occasionally resulting in 504 gateway errors for regular administrative operations across our instance.
We tried mitigating this by introducing an in-memory TTL cache and Redis caching layer within our custom endpoint extension to ensure that identical reference numbers retrieved within the last twenty-four hours serve cached payload snapshots immediately. However, we are struggling with how to cleanly handle cold cache misses during upstream outages without leaving the client hanging, as well as how to structure an asynchronous fallback queue using Directus Flows or BullMQ so failed upstream lookups can retry in the background without blocking active API workers.
I would love to know if the community recommends offloading this kind of unpredictable external HTTP aggregation entirely to a separate worker proxy outside of Directus, or if there is a well-established pattern within Directus custom endpoints and Flow webhooks to gracef