API design, reliability, and scaling patterns for production Django services.
I would model tenant identity at the request boundary, enforce row-level access in every query path, and back it with database constraints where possible. For larger scale, I would evaluate schema-per-tenant vs shared-schema with tenant keys based on isolation needs, operational cost, and migration complexity.
I profile query counts first, then use select_related for one-to-one or foreign key joins and prefetch_related for many-to-many collections. I also keep serializer logic explicit so expensive nested relations are only loaded when the endpoint truly needs them.
I move expensive work into task queues (for example Celery) with idempotent tasks, retries, and dead-letter handling. The API returns immediately with job state, and I expose progress/status endpoints so users can track completion without blocking web workers.