One thing I’d add is that scaling problems often become noticeable before you actually need to split a Python backend into multiple services. Database queries and request-handling time are usually worth investigating first.

For example, an API endpoint that performs several queries or waits for slow external services can become a bottleneck as traffic increases. Moving expensive or non-urgent work to a background worker can help keep request latency predictable.

I also think observability becomes increasingly important at this stage. Tracking query duration, endpoint latency, error rates, and queue times makes it much easier to identify the actual bottleneck instead of optimizing based on assumptions.

The key is probably to measure first and introduce architectural complexity only when the application’s real workload justifies it.