E-Doc

Document processing is slow and it fails for boring reasons — a large file, a rate-limited third party, a cold start that runs past the timeout. Doing that work inside the HTTP request means the user watches a spinner and then gets an error that loses everything the job had already done.

Moving it to a job queue changes the failure mode. The upload succeeds immediately, the processing becomes a sequence of steps that can be retried independently, and a transient failure in step four does not throw away steps one through three.

Uploads go through UploadThing and are recorded in PostgreSQL through Prisma, at which point the request is done and the user gets their page back. That write emits an Inngest event, and the processing runs as durable steps outside the request lifecycle, with retries handled by the platform rather than by a loop I wrote.

Authentication is Clerk. The processed results are aggregated and rendered as Recharts dashboards, so the output of all that background work is something the user can actually read rather than a status column that says `complete`.

The honest difficulty with background processing is that it moves the problem into the interface. The user uploaded something and now nothing appears to be happening, which feels broken even though it is working exactly as designed.

So the queue has to be visible. Showing which documents are pending, which finished and which failed turns an invisible system into an understandable one, and it is the difference between a user waiting patiently and a user uploading the same file four times.