In Plotly Dash, how do you stop a 60-second query in a callback from freezing the app?

## Why a slow callback is an availability problem Every ordinary Dash callback executes synchronously inside the HTTP request that triggered it. The WSGI worker handling that request is blocked for the duration. With `gunicorn -w 4`, four concurrent 60-second callbacks consume every worker; the fifth user cannot even load the page, because serving the initial layout is also a request. A slow callback is therefore not merely a slow chart — it is a denial of service against your own app, and the failure looks like a total outage rather than one sluggish panel. ## Background callbacks Dash 2.x supports running a callback outside the request cycle. The mechanism arrived as `long_callback` and was reworked into a flag on the normal decorator: ``` from dash import Dash, callback, Input, Output, CeleryManager background_manager = CeleryManager(celery_app) @callback( Output("result", "data"), Input("run", "n_clicks"), background=True, manager=background_manager, running=[(Output("run", "disabled"), True, False)], cancel=[Input("cancel", "n_clicks")], prevent_initial_call=True, ) def heavy(n): ... ``` When the callback fires, Dash enqueues the job with the manager and returns immediately; the browser polls for completion and patches the outputs when the result lands. The request worker is free the entire time. **Manager choice matters.** `DiskcacheManager` uses the local `diskcache` library and is documented for development: it depends on a shared local filesystem, which does not hold across containers or hosts. `CeleryManager` submits to a Celery broker (typically Redis or RabbitMQ) with separate worker processes you deploy and scale independently — that is the production configuration, and it is also what makes the job survive a web-process restart. **The supporting arguments.** `running` takes a list of `(Output, value_while_running, value_when_done)` triples — disable the run button, enable the cancel button, swap a label. `cancel` takes inputs that abort the job. `progress` designates an output the function can update through an injected `set_progress` callable, driving a progress bar (dash-bootstrap-components' `dbc.Progress`, say) or a plain text counter. ## The lighter tools, and when they are enough `dcc.Loading` wraps a component and shows a spinner while any callback writing into it is in flight. It is a **UX** fix, not a concurrency fix: the worker is still blocked. Use it always, because an un-spinnered app looks broken during a two-second query — but never as the answer to a 60-second one. `dcc.Interval` fires a callback on a timer and is the right tool for polling a job you launched elsewhere, or for a live-refresh panel. Used carelessly it is a self-inflicted load generator: a one-second interval on a page with fifty viewers is fifty queries a second against the warehouse forever. Caching sits in front of everything. If the 60 seconds is spent recomputing what ten users already asked for, memoise on the callback's arguments with Flask-Caching over Redis and the second caller waits milliseconds. This is often the entire fix. ## Ask the upstream question first Before reaching for background execution, interrogate the 60 seconds: - **Is it firing too often?** A dropdown wired as `Input` recomputes per change. Move the form fields to `State` and trigger on a submit button, and the query count collapses. - **Is the warehouse doing work the model should have done?** A dashboard scanning raw fact tables per interaction wants a pre-aggregated table or a materialised view. Sub-second interaction on a modelled aggregate beats a beautifully engineered progress bar over a bad query. - **Is the payload the problem?** Returning a hundred thousand rows to a table serialises to JSON, crosses the wire, and renders in the browser. Paginate or aggregate server-side. - **Is this an app at all?** Some "slow dashboards" are batch reports wearing a dashboard costume. Materialise the answer on a schedule and serve it. ## What an interviewer is checking They want to hear the availability framing — that a synchronous callback holds a worker and that concurrency, not latency, is what breaks — plus the concrete mechanism (background callback, Celery manager in production, `running`/`cancel`/`progress`), plus the instinct to attack the query and the trigger pattern before adding infrastructure. Naming only `dcc.Loading` is the weak answer, because it makes the frozen app look prettier while it is still frozen.