Is using Google Cloud Tasks to invoke an internal Django endpoint effectively asynchronous (even under WSGI)?

I'm running a Django application on Google Cloud Run using the default WSGI-based setup (e.g., Gunicorn/ runserver for local dev).

To avoid blocking during long-running operations like third-party API calls, I'm planning to use Google Cloud Tasks.

Current design:

A request comes in to a Django endpoint (e.g., a webhook or ping from an external service)

Instead of processing the request inline, I enqueue a Cloud Task

That task posts to another Django endpoint within the same service, which performs the third-party API call using data passed in the task payload

This means:

I'm not offloading the work to a separate Cloud Run service

The fetch logic is still part of the same Django service/container, just decoupled by the task

My question:

Does this setup allow the third-party call to be effectively asynchronous (i.e., non-blocking to the original request), despite using WSGI and not ASGI or Celery?

When searching around, I mostly see articles and examples where Cloud Tasks are used to call a separate Cloud Run service, not another internal route in the same app.

Is this internal invocation pattern valid and scalable under WSGI, or are there caveats I should be aware of?

Вернуться на верх