Python Developer Interview Questions

Python variables do not contain values in the same sense as fixed memory slots in some lower-level languages. A variable name is bound to an object.

For example:

`python

a = [1, 2]

b = a

Both a and b refer to the same list object. Mutating that list through either name is visible through the other name.

Mutable objects

Mutable objects can change after creation.

Common mutable built-in types include:

For example, list.append() modifies an existing list rather than creating a completely independent list.

Immutable objects

Immutable objects cannot be modified in place after creation.

Common examples include:

An operation that appears to modify an immutable value instead creates or obtains another object and rebinds the name.

For example:

`python

name = "Python"

name += " Developer"

The string itself is not mutated in place.

Identity versus equality

is tests whether two references point to the same object.

== tests whether two objects should be considered equal according to their equality behavior.

For example:

`python

a = [1, 2]

b = [1, 2]

print(a == b) # True

print(a is b) # False

The lists contain equivalent values but are separate objects.

Use is for identity-sensitive checks, particularly singleton values such as None:

`python

if value is None:

...

Do not use is as a general replacement for equality comparison.

Aliasing

When multiple names refer to the same mutable object, the references are aliases.

Aliasing can be useful, but accidental shared mutation is a frequent source of bugs.

Tuples and mutability

A tuple is immutable, meaning its references cannot be replaced after construction. However, a tuple can contain mutable objects.

For example:

`python

value = ([1, 2], "active")

value[0].append(3)

The tuple structure remains unchanged while the contained list is mutated.

Understanding names, objects, identity, and mutability is fundamental to reasoning about function arguments, copying, dictionaries, caching, and application state.

Python provides several built-in collection types, and choosing the right one improves correctness, readability, and performance.

List

A list is an ordered, mutable sequence.

Use it when:

Example:

`python

jobs = ["backend", "frontend", "devops"]

jobs.append("data")

Lists support indexing and slicing.

Tuple

A tuple is an ordered, immutable sequence.

Use it when a group of values conceptually forms a fixed record or should not have its positions replaced after construction.

Example:

`python

coordinate = (40.7, -74.0)

Tuples can sometimes be used as dictionary keys if all values participating in their hash are hashable.

Set

A set stores unique hashable elements and is particularly useful for membership testing, deduplication, and mathematical set operations.

Examples include:

`python

required = {"python", "sql"}

candidate = {"python", "docker", "sql"}

missing = required - candidate

Do not rely on a set for meaningful positional ordering.

Dictionary

A dictionary maps unique hashable keys to values.

Use it when information should be retrieved by a meaningful key rather than by position.

`python

candidate = {

"name": "Alex",

"score": 92,

}

Modern Python dictionaries preserve insertion order, but the primary reason to choose a dictionary is key-based mapping rather than positional indexing.

Hashability

Set elements and dictionary keys need to be hashable.

Many immutable objects are hashable, but immutability alone should not be treated as a complete definition of hashability. User-defined types can customize equality and hashing behavior.

Lists and dictionaries themselves are not hashable and therefore cannot directly be dictionary keys.

Choosing by access pattern

A strong developer chooses collections based on operations rather than habit.

Examples:

The appropriate structure makes the intended semantics obvious and avoids unnecessary scanning or conversion.

Understanding copying requires distinguishing an object from the references that point to it.

Assignment

Assignment does not copy an object.

`python

original = [[1, 2], [3, 4]]

alias = original

original and alias refer to the same outer list.

Changing either reference changes the same object.

Shallow copy

A shallow copy creates a new outer compound object but places references to the original nested objects inside it.

For example:

`python

import copy

original = [[1, 2], [3, 4]]

shallow = copy.copy(original)

Now:

`python

original is shallow

is false because the outer lists are different.

But:

`python

original[0] is shallow[0]

is true because the nested list is still shared.

Therefore:

`python

shallow[0].append(99)

also changes original[0].

Many built-in containers provide convenient shallow-copy operations such as:

Deep copy

copy.deepcopy() recursively constructs independent copies of nested objects where appropriate.

This is useful when the copied object graph must be modified independently.

However, deep copying should not be automatic or indiscriminate.

Potential problems include:

The deepcopy implementation maintains a memo of objects already copied so recursive structures can be handled and unnecessary duplicate copying can be avoided.

Design alternatives

Sometimes the better solution is not copying at all.

Alternatives include:

Copy only when independent ownership is actually required.

Python iteration is built around the iterable and iterator protocols.

Iterable

An iterable is an object that can provide an iterator.

Examples include:

Calling iter() on an iterable obtains an iterator.

Iterator

An iterator produces values one at a time through next().

When no values remain, it raises StopIteration.

A for loop performs this protocol automatically.

Conceptually:

`python

iterator = iter(values)

while True:

try:

value = next(iterator)

except StopIteration:

break

Generators

A generator function contains yield.

Calling the function returns a generator object rather than executing the entire function immediately.

Each next() resumes execution until another value is yielded or the function finishes.

`python

def read_ids(rows):

for row in rows:

yield row["id"]

Generators are useful for streams, files, paginated input, pipelines, and large datasets.

Generator expressions

A generator expression resembles a list comprehension but uses parentheses.

`python

squares = (number * number for number in range(1_000_000))

The values are produced incrementally.

By contrast:

`python

squares = [number * number for number in range(1_000_000)]

constructs the entire list immediately.

Lazy evaluation

Lazy processing can reduce peak memory because data does not need to be materialized all at once.

It can also allow processing to begin before every input is available.

However, generators are not automatically superior.

Materializing a collection may be appropriate when:

One-shot consumption

Many iterators are consumed as they are traversed.

A common bug is to iterate over a generator once and expect the same values to remain available for another pass.

Design APIs so it is clear whether they accept reusable collections or one-pass iterators.

Python programs generally do not manually allocate and free individual objects. Memory management is handled by the runtime.

It is important to distinguish Python language semantics from implementation details. CPython is the dominant Python implementation, but alternative Python implementations may manage memory differently.

Reference counting in CPython

CPython tracks references to objects.

Conceptually, when an object no longer has references keeping it reachable, its storage can usually be reclaimed promptly.

For example:

`python

value = SomeObject()

other = value

del value

Deleting value removes one name binding, but other still refers to the object.

del therefore does not mean “free this object immediately.” It removes a reference or binding according to context.

Reference cycles

Reference counting by itself cannot reclaim certain cycles.

For example, object A may reference object B while object B references object A, even though neither is reachable from the application anymore.

CPython therefore also includes a cyclic garbage collector.

The gc module provides interfaces for inspecting and controlling this collector.

Why memory usage may not immediately fall

Even after Python objects are reclaimed, process-level memory usage does not necessarily decrease immediately.

The interpreter and underlying allocators can retain memory for future allocations.

Therefore, operating-system resident memory is not a direct count of live Python objects.

Common sources of memory growth

Long-running applications should investigate patterns such as:

Not every increase is a garbage-collector problem.

Garbage collection is not resource management

Files, database connections, locks, and network resources should normally be managed explicitly.

Context managers are the preferred pattern for deterministic cleanup:

`python

with open(path) as file:

data = file.read()

Do not rely on garbage collection timing to release important external resources.

Tuning

Changing garbage-collector thresholds or disabling the collector should only follow measurement and a clear understanding of the workload.

Premature GC tuning can hide the real cause of memory growth or degrade performance.

A memory-efficient Python pipeline should control how much data is simultaneously live rather than relying on garbage collection to rescue an architecture that materializes everything.

1. Understand the workload

Measure:

Do not optimize based only on record count because object representation can make similarly sized datasets consume very different amounts of memory.

2. Stream where possible

Avoid loading an entire dataset when each record can be processed independently.

Prefer iterators or generators:

`python

def read_records(stream):

for line in stream:

yield parse(line)

This allows downstream processing to consume records incrementally.

3. Use bounded batching

Many databases, APIs, and vectorized operations perform better with batches.

Batching does not require loading the entire dataset.

A pipeline can process, for example, 500 or 1,000 records at a time and release the batch before moving forward.

The correct size should be measured against throughput, memory, network, and database behavior.

4. Choose data structures intentionally

Use structures according to access patterns.

Examples:

Do not maintain a million-element list merely because list is familiar.

5. Avoid unnecessary copies

Watch for operations that duplicate large data structures:

Transform records as close as possible to when they are consumed.

6. Bound application state

Caches, retry queues, deduplication maps, metrics labels, and aggregation dictionaries can become memory leaks from an operational perspective even when every object remains legitimately reachable.

Define explicit limits and eviction policies.

7. Separate Python memory from external resources

Memory issues may involve:

Measure the complete process rather than assuming every increase comes from Python objects.

8. Profile before tuning

Use representative workloads and tools such as tracemalloc for Python allocation analysis.

Compare snapshots to identify which code paths retain allocations.

Also measure:

9. Diagnose retention rather than forcing collection

Repeatedly calling gc.collect() is not a general solution to memory growth.

If objects remain reachable through a cache, global structure, queue, callback, or application state, garbage collection correctly keeps them alive.

Fix the ownership or retention policy.

10. Apply backpressure

If producers create data faster than consumers process it, an unbounded queue eventually consumes available memory.

Use bounded queues or flow-control mechanisms so producers slow down when downstream processing reaches capacity.

11. Optimize representation only when necessary

For very large datasets, object overhead can matter.

Depending on the workload, alternatives may include compact serialized representations, arrays, database-side processing, or specialized libraries.

Choose them after profiling rather than sacrificing readability prematurely.

12. Validate production behavior

A successful design should demonstrate bounded memory under sustained load, acceptable throughput, predictable failure behavior, and stable resource use over long-running tests.

A Python class defines a type whose instances can hold state and expose behavior.

Defining a class

A class is created with the class statement:

`python

class Candidate:

pass

Calling the class normally creates an instance:

`python

candidate = Candidate()

Instance attributes

Instance attributes belong to a specific object.

They are commonly initialized in __init__:

`python

class Candidate:

def __init__(self, name: str):

self.name = name

Each instance can hold a different value:

`python

first = Candidate("Alex")

second = Candidate("Jordan")

first.name and second.name are independent instance attributes.

Instance methods

An instance method is a function defined inside a class that receives the instance as its first argument by convention named self.

`python

class Candidate:

def __init__(self, name: str):

self.name = name

def display_name(self) -> str:

return self.name

Calling:

`python

candidate.display_name()

causes Python to bind candidate to the method’s self parameter.

Class attributes

A class attribute is stored on the class and can be shared by instances unless shadowed by an instance attribute.

`python

class Candidate:

platform = "ResumeLoopAI"

All instances can access platform through normal attribute lookup.

Be careful when using mutable objects as class attributes because all instances can observe the same shared object.

Attribute lookup

For ordinary instance access, Python first considers attributes associated with the instance and then follows class and inheritance lookup rules.

Descriptors and special methods can participate in this behavior, so Python attribute access is richer than a simple dictionary lookup.

Encapsulation conventions

Python generally relies on conventions rather than strict private access modifiers.

A leading underscore, such as _internal_state, conventionally communicates that an attribute is intended for internal use.

Names beginning with two underscores can trigger name mangling inside a class, but this should not be treated as a security boundary.

The important design goal is to expose a clear public interface rather than depend on enforced privacy.

Python supports inheritance, but inheritance should be used because it models a meaningful relationship rather than simply to reuse code.

Inheritance

A subclass inherits accessible behavior from a base class.

`python

class Notification:

def send(self) -> None:

raise NotImplementedError

class EmailNotification(Notification):

def send(self) -> None:

print("Sending email")

EmailNotification is a specialized form of Notification.

Method overriding

A subclass can define a method with the same name as one available from a base class.

The subclass implementation is selected according to Python’s method-resolution rules.

This supports polymorphic behavior:

`python

def deliver(notification: Notification):

notification.send()

Different notification implementations can behave differently while exposing the same interface.

super()

super() allows a method to delegate to the next implementation in the method resolution order.

It is commonly used when extending initialization or cooperative behavior:

`python

class EmailNotification(Notification):

def __init__(self, address: str):

super().__init__()

self.address = address

In multiple-inheritance hierarchies, super() follows the method resolution order rather than simply meaning “call my direct parent.”

Composition

Composition means building an object using other objects as collaborators.

`python

class ResumeService:

def __init__(self, repository):

self.repository = repository

The service uses a repository but is not a repository.

Composition is often preferable when:

Inheritance versus composition

Inheritance can be useful for stable conceptual hierarchies and framework extension points.

Composition is frequently easier to evolve because behavior can be assembled from independent objects rather than inherited through a deep hierarchy.

A good design minimizes accidental coupling and makes the relationship between components explicit.

Python’s data model allows custom classes to participate in language syntax and built-in operations by implementing special methods, often called dunder methods.

These methods should implement established protocols rather than be called arbitrarily by application code.

Representation

__repr__ should return an unambiguous and useful representation of an object, particularly for debugging.

`python

class Job:

def __repr__(self):

return f"Job(id={self.id!r})"

__str__ can provide a more user-oriented textual representation.

Equality

__eq__ defines how objects compare using ==.

If custom equality is based on selected fields, hashing must remain consistent with that definition when objects are hashable.

Hashing

Objects used as dictionary keys or set members require stable hashing behavior while stored in those collections.

The core requirement is:

If two objects compare equal, their hash values must also be equal.

Mutable objects whose equality-relevant fields can change are generally poor hash keys because changing their hash-related state after insertion can break lookup assumptions.

Length

Implementing __len__ allows len(object) to work.

Python also uses length in truth-value testing when __bool__ is not defined.

Iteration

Implementing __iter__ allows an object to participate in iteration.

For a container, __iter__ commonly returns an iterator over contained values.

Containment

__contains__ can customize value in object behavior.

If it is absent, Python may fall back to iteration-based behavior depending on the object.

Context management

Other protocol methods include __enter__ and __exit__, which support the with statement.

Operator overloading

Methods such as __add__ or __lt__ can define operator behavior.

They should be implemented only when the operation has clear semantics for the domain.

The key design principle is that special methods should make custom objects behave naturally within established Python protocols rather than create surprising meanings for familiar operations.

Python functions are first-class objects. They can be assigned to variables, stored in collections, passed as arguments, and returned from other functions.

Higher-order functions

A higher-order function accepts another function, returns one, or both.

Examples include built-ins such as map() and APIs that accept callbacks or key functions.

`python

sorted(users, key=lambda user: user.name)

Here, the callable passed to key determines the sorting value.

Closures

A nested function can reference variables from an enclosing scope.

When the nested function remains accessible after the outer function returns, it can retain access to those bindings.

`python

def multiplier(factor):

def multiply(value):

return value * factor

return multiply

The returned function closes over factor.

Late binding

Closures capture variables by binding, not by freezing their value automatically at function creation.

A common example occurs when creating functions in a loop.

If each callback references the same loop variable, they may all observe its final value later.

One solution is to bind the current value explicitly through a default argument or helper function.

Decorators

A decorator transforms a callable or class using @decorator syntax.

Conceptually:

`python

@trace

def execute():

...

is similar to:

`python

execute = trace(execute)

Decorators are useful for cross-cutting behavior such as:

They are less appropriate when wrapping hides important business control flow or creates difficult-to-debug behavior.

Preserving metadata

A wrapper can hide the original function’s name, documentation, and metadata.

functools.wraps should commonly be applied to wrappers so introspection remains useful.

Parameterized decorators

A decorator can accept configuration by introducing another function level.

For example, @retry(max_attempts=3) first creates the configured decorator and then wraps the target callable.

Keep decorators focused and predictable. If a decorator changes return types, silently swallows exceptions, or introduces major side effects, callers may struggle to understand normal control flow.

Python provides several mechanisms for building expressive object models without requiring large amounts of repetitive code.

Dataclasses

The dataclasses module can generate methods such as __init__, __repr__, and equality behavior from declared fields.

`python

from dataclasses import dataclass

@dataclass

class Candidate:

name: str

score: int

Dataclasses are useful for objects primarily representing structured application data.

Options include:

These options change behavior and should be chosen intentionally.

frozen=True prevents ordinary field assignment through generated controls but should not automatically be interpreted as deep immutability if fields themselves reference mutable objects.

Default factories

Mutable defaults should normally use field(default_factory=...):

`python

from dataclasses import dataclass, field

@dataclass

class Profile:

skills: list[str] = field(

default_factory=list

)

This prevents different instances from unintentionally sharing one mutable default.

Properties

property lets a method be accessed through attribute syntax.

It is useful when an attribute needs validation, computation, compatibility logic, or controlled mutation.

`python

class Candidate:

@property

def score(self):

return self._score

A setter can validate assignment while keeping a simple attribute-facing API.

Properties are particularly useful when a previously public attribute later requires implementation logic without forcing all callers to switch to explicit getter methods.

Descriptors

A descriptor is an object whose class implements methods such as:

Descriptors allow reusable control over attribute behavior.

Properties themselves are implemented using the descriptor protocol.

Frameworks and libraries use descriptors for patterns including:

Choosing the mechanism

Use a dataclass when the object is predominantly structured data.

Use a property when one class needs controlled behavior around a small number of attributes.

Use a custom descriptor when the same attribute-management behavior should be reusable across many classes or fields.

Avoid using these mechanisms simply to make code look more advanced. The abstraction should reduce duplication or protect a meaningful invariant.

Large Python systems benefit from both object-oriented and functional techniques, but neither style should become a rule applied everywhere.

The objective is to make ownership, dependencies, state changes, and business behavior easy to understand and test.

1. Separate domain behavior from infrastructure

Core business rules should not depend unnecessarily on web frameworks, databases, message brokers, or vendor SDKs.

For example, resume scoring logic can operate on domain values while database persistence is handled by a repository boundary.

This makes domain behavior easier to test and reduces framework coupling.

2. Keep dependencies explicit

Prefer passing collaborators through constructors or function arguments rather than importing mutable global service instances throughout the application.

Explicit dependencies improve:

3. Prefer composition over deep inheritance

Use inheritance when there is a stable semantic hierarchy or protocol relationship.

Use composition for interchangeable collaborators such as:

Deep inheritance trees often make behavior depend on implementation details distributed across many classes.

4. Keep pure transformations pure where practical

A pure function depends only on its inputs and produces a result without hidden side effects.

Such functions are useful for:

Pure functions are easy to test and compose.

Not all application code can or should be pure. Database writes, HTTP requests, logging, and message publication are inherently effectful.

The useful pattern is to isolate effects rather than pretend they do not exist.

5. Model state deliberately

Avoid uncontrolled shared mutable state.

Prefer:

Stateful objects are appropriate when identity and lifecycle matter, but mutation should have clear ownership.

6. Use protocols and small interfaces

Python supports structural typing through typing.Protocol.

Consumers can depend on the behavior they need rather than one concrete implementation.

This often provides flexibility without requiring large inheritance hierarchies.

7. Avoid premature abstraction

Do not introduce base classes, strategy objects, factories, registries, and decorators before actual variation exists.

A duplicated three-line function may be easier to maintain than a generic abstraction that tries to predict future requirements.

Refactor when stable patterns become visible.

8. Keep side effects near boundaries

One useful architecture is:

This keeps the center of the application easier to test while effects remain visible at the edges.

9. Preserve exception boundaries

Domain exceptions should represent business failures.

Infrastructure-specific exceptions can be translated at boundaries when callers should not know about the underlying technology.

Do not catch every exception and convert all failures into generic values because this destroys diagnostic information.

10. Use data models intentionally

Possible choices include:

Convert loosely structured external data into stronger internal representations early.

11. Keep decorators and metaprogramming constrained

Decorators are useful for consistent cross-cutting concerns, but extensive hidden behavior makes control flow difficult to follow.

Prefer explicit application code when the business consequence of an operation is important.

12. Optimize for testability and change

A healthy architecture allows business logic to be tested without starting the complete application stack.

It should also allow one infrastructure component to be replaced without rewriting unrelated domain code.

The best architecture is not the one with the most patterns. It is the one that makes current behavior and likely change inexpensive to understand.

Concurrency and parallelism are related but different concepts.

Concurrency

Concurrency means a program can make progress on multiple tasks during overlapping periods of time.

The tasks do not necessarily execute at the exact same instant.

For example, a program can start several network requests and work on whichever request is ready while the others wait for I/O.

Parallelism

Parallelism means multiple operations actually execute simultaneously, commonly on different CPU cores.

A system can be concurrent without being parallel.

Threads

Threads share memory within one process.

They can be useful for work that spends significant time waiting on blocking I/O, such as:

Shared memory makes communication convenient but also introduces synchronization concerns.

Traditional CPython builds use a Global Interpreter Lock, commonly called the GIL, which limits simultaneous execution of Python bytecode by multiple threads in one interpreter.

However, this should not be described as a universal property of all Python runtimes. Modern Python also supports free-threaded builds where the GIL can be disabled.

Therefore, performance assumptions should be tied to the Python implementation and build actually being used.

Processes

Processes normally have separate memory spaces.

Process-based execution can be useful for CPU-intensive workloads because independent Python processes can execute across multiple CPU cores.

Examples include:

The tradeoffs include:

asyncio

asyncio provides cooperative concurrency around an event loop.

It is particularly useful when an application needs to handle many I/O operations concurrently and the libraries involved provide asynchronous APIs.

Examples include:

asyncio does not make CPU-heavy Python code automatically non-blocking. CPU-intensive work executed directly on an event-loop thread can prevent other tasks from progressing.

Choosing an approach

A useful starting point is:

The correct choice should be based on measured workload behavior rather than a rule that one concurrency model is always better.

asyncio provides an event-driven concurrency model built around coroutines, tasks, futures, and an event loop.

Coroutine functions

A function declared with async def is a coroutine function.

Calling it produces a coroutine object:

`python

async def fetch_data():

...

coroutine = fetch_data()

Calling the function does not execute the complete operation synchronously like a normal function call.

The coroutine must be awaited or scheduled.

await

await suspends the current coroutine until the awaited operation can make progress or complete.

During an appropriate suspension point, the event loop can run other ready tasks.

For example:

`python

await asyncio.sleep(1)

allows other scheduled work to run while the task is waiting.

This is cooperative scheduling: tasks yield control at defined suspension points.

Event loop

The event loop coordinates runnable tasks, callbacks, timers, and I/O readiness.

Modern applications normally use high-level entry points such as:

`python

asyncio.run(main())

rather than manually constructing and controlling an event loop.

Tasks

A coroutine does not automatically run concurrently with another coroutine merely because both functions use async def.

asyncio.create_task() schedules a coroutine for concurrent execution by the event loop.

For example:

`python

first = asyncio.create_task(fetch_first())

second = asyncio.create_task(fetch_second())

await first

await second

Both tasks can make progress while their asynchronous operations wait.

Sequential awaiting

This code:

`python

first = await fetch_first()

second = await fetch_second()

normally waits for the first operation before beginning the second.

If they are independent, creating tasks or using structured concurrency can allow them to overlap.

Blocking the event loop

Code inside an async function is not automatically asynchronous.

Examples that can block the event loop include:

Use asynchronous libraries or explicitly offload appropriate blocking work.

asyncio is not synonymous with parallelism

A normal event loop uses cooperative scheduling between tasks. It is designed primarily to make efficient progress across waiting operations.

The major benefit is often concurrency with large numbers of I/O operations rather than CPU parallelism.

A race condition occurs when a program’s correctness depends on the timing or interleaving of concurrent operations.

Shared mutable state is a common source of these problems.

A simple race

Suppose multiple workers perform a logical operation such as:

1. Read current balance

2. Calculate a new balance

3. Write the new balance

If two workers interleave those steps without coordination, one update may overwrite another.

The important point is that a source-code expression that looks simple should not automatically be assumed to provide the application-level atomicity required by the invariant.

Locks

A lock protects a critical section so only one participating thread enters it at a time.

`python

with lock:

update_shared_state()

Keep critical sections as small as correctness permits.

Holding a lock while performing slow network or disk operations can unnecessarily serialize the application.

RLock

A reentrant lock can be acquired repeatedly by the same thread and must be released the corresponding number of times.

It is useful when synchronized methods can legitimately call other methods requiring the same lock, but it should not be used merely to hide unclear locking design.

Semaphore

A semaphore allows a bounded number of concurrent entrants.

It is useful for limiting access to scarce resources such as:

Event

An event communicates that some condition or state transition has occurred.

For example, workers can wait until initialization has completed.

Condition

A condition combines synchronization with waiting for a state predicate to become true.

Conditions are appropriate for coordinated producer-consumer state beyond simple signalling.

Queues

Thread-safe queues often provide a better design than manually sharing mutable lists between producers and consumers.

A queue establishes clearer ownership transfer and can support bounded capacity.

asyncio synchronization

asyncio provides asynchronous versions of locks, semaphores, events, and conditions.

These coordinate tasks within asynchronous execution and should not be assumed to provide thread synchronization. Python documentation explicitly notes that asyncio synchronization primitives are not thread-safe.

Deadlocks

A deadlock can occur when participants wait indefinitely for resources held by one another.

Reduce risk by:

The best concurrency design frequently reduces shared mutable state rather than adding increasingly complex synchronization around it.

Production asynchronous programs need lifecycle and resource management in addition to async and await syntax.

Unbounded task creation can exhaust memory, connection pools, file descriptors, or upstream capacity even when every individual operation is asynchronous.

Structured concurrency

Related concurrent operations should normally have an identifiable owner and lifetime.

asyncio.TaskGroup provides structured management of related tasks.

`python

async with asyncio.TaskGroup() as group:

group.create_task(fetch_one())

group.create_task(fetch_two())

Exiting the context waits for the group according to its defined failure and cancellation behavior.

This is generally safer than scattering unmanaged background tasks across application code.

Task references

If genuinely long-lived background tasks are created directly, their lifetime must still be managed.

Current Python documentation notes that the event loop keeps weak references to tasks, so reliable background-task patterns should preserve appropriate strong references until completion.

Cancellation

Cancellation is part of normal async control flow.

A task may be cancelled because:

Cleanup should use try/finally or asynchronous context managers.

Do not casually suppress cancellation and continue expensive work after the caller no longer needs the result.

Timeouts and deadlines

Every external dependency can stall.

Use explicit deadlines for operations such as:

A timeout should trigger defined handling rather than merely writing a log entry and leaving work running indefinitely.

Bounded concurrency

Starting 100,000 asynchronous requests simultaneously may overwhelm the destination or local resource pools.

Use mechanisms such as:

The appropriate concurrency limit should be measured against latency, throughput, rate limits, memory, and downstream capacity.

Backpressure

Backpressure prevents producers from indefinitely generating work faster than consumers can process it.

A bounded queue is a common mechanism.

When the queue reaches capacity, producers must wait, reject work, spill it to durable storage, or apply another explicit policy.

Failure propagation

Concurrent tasks should have defined failure semantics.

Ask:

Task groups are useful when related tasks should be treated as one structured operation.

Graceful shutdown

During shutdown:

1. Stop accepting new work

2. Signal workers

3. Allow bounded graceful completion

4. Cancel remaining tasks if needed

5. Close clients and pools

6. Flush required state

A production async system should have bounded concurrency and bounded lifetime, not simply a large collection of concurrently scheduled coroutines.

Performance work should begin with evidence.

A slow application can be limited by very different resources, and each type of bottleneck requires a different solution.

1. Define the performance problem

Start with a measurable objective such as:

Avoid optimizing code merely because it looks inefficient.

2. Use representative workloads

Development examples with ten records may behave very differently from production inputs with millions of records or high concurrency.

Benchmark realistic:

3. Determine the bottleneck category

Ask whether time is primarily spent on:

Do not optimize Python loops when the real bottleneck is a database query.

4. CPU profiling

Python provides cProfile and related profiling tools that can identify where execution time accumulates.

Focus on expensive call paths rather than optimizing every frequently invoked function.

5. Microbenchmarking

timeit is useful for measuring small Python operations while reducing some common timing noise.

Microbenchmarks should answer narrow questions and should not substitute for end-to-end application measurements.

6. Memory profiling

tracemalloc can trace Python memory allocations and compare snapshots.

It can help identify code paths responsible for growing Python allocations.

Remember that process resident memory can include native allocations and other memory not fully represented by Python-level tracing.

7. Algorithmic improvements first

Changing an algorithm or eliminating unnecessary work frequently matters more than micro-level syntax changes.

Examples include:

8. Reduce allocation and copies

Large workloads can benefit from:

9. Optimize I/O differently from CPU

If the application waits on I/O, reducing CPU instructions may provide little user-visible improvement.

Instead consider concurrency, batching, connection reuse, indexing, caching, or fewer network round trips.

10. Verify after every meaningful change

Compare before and after using the same methodology.

An optimization is successful only if it improves the target metric without unacceptable regressions in correctness, memory, complexity, or reliability.

Readable code should not be sacrificed for tiny improvements that do not matter at application scale.

A production Python concurrency architecture should match execution mechanisms to workload characteristics rather than placing every operation into one generic concurrency model.

1. Classify work first

Separate operations into categories such as:

This determines where each operation should execute.

2. Keep event-loop code non-blocking

For an asyncio-based API, asynchronous network operations can run directly through async-compatible clients.

Do not perform long CPU calculations or blocking SDK operations directly on the event-loop thread.

Blocking work may need to be offloaded to a thread, process, or external worker depending on its behavior.

3. Isolate CPU-intensive work

For CPU-heavy independent operations, process-based workers are often a suitable design on conventional CPython deployments because they provide interpreter isolation and multi-core execution.

Modern free-threaded Python changes some threading assumptions, but architecture should still be validated against the exact runtime, extension ecosystem, and workload rather than assuming threads automatically become the optimal CPU strategy.

Heavy computation may also belong in a separate worker service when it requires independent scaling or resource limits.

4. Bound every concurrency layer

Concurrency must have explicit limits.

Examples include:

Without bounds, overload moves from one component to another until the system fails through memory growth, connection exhaustion, or downstream saturation.

5. Apply backpressure

When downstream capacity is full, the system needs an explicit policy.

Possible responses include:

An unlimited in-memory queue is not a capacity strategy.

6. Propagate deadlines

If the user request has five seconds remaining, a downstream operation should not independently wait for thirty seconds.

Propagate time budgets where practical so abandoned work does not continue consuming resources unnecessarily.

7. Define cancellation semantics

When a client disconnects or parent task fails, decide which child operations should stop.

Do not cancel an operation that has already performed an irreversible side effect unless its consistency model safely supports that behavior.

8. Separate durable work from request lifetime

Work that must complete despite client disconnects should not live only as an in-memory detached asyncio task.

Examples include:

Use durable queues or another persistent job mechanism when completion guarantees matter.

9. Design idempotency and retries

Retries can duplicate side effects.

Use idempotency keys, transaction boundaries, deduplication, or operation-specific semantics where repeated execution would otherwise be unsafe.

Retry only failures likely to be transient, and use bounded attempts with delay or backoff.

10. Protect dependencies independently

One slow external API should not consume every available worker.

Use per-dependency concurrency limits, timeouts, and pools so failure is isolated.

11. Observe saturation

Monitor more than request rate.

Important signals include:

Scaling workers without understanding saturation can worsen dependency overload.

12. Shut down gracefully

A deployment or termination should:

1. Stop accepting new work

2. Drain or transfer appropriate queued work

3. Allow bounded completion

4. Cancel remaining safe-to-cancel tasks

5. Close clients and executors

6. Preserve durable work

13. Load test failure behavior

Test not only normal peak traffic but also:

A scalable system is one that degrades predictably when capacity is exceeded, not merely one that performs well under ideal conditions.

Testing levels differ mainly in scope, dependencies, speed, and the kinds of failures they are designed to catch.

Unit tests

A unit test exercises a small piece of behavior in relative isolation.

Typical examples include:

Good unit tests are usually fast and deterministic.

They are useful for checking many edge cases because failures are often easy to localize.

Integration tests

An integration test verifies that multiple real components work together.

Examples include:

Integration tests are usually slower but can detect failures that mocks cannot reveal, such as schema mismatches, SQL errors, environment configuration problems, and incompatible assumptions between components.

Test behavior rather than implementation details

A test should usually verify externally meaningful behavior rather than internal line-by-line mechanics.

For example, testing that a pricing function returns the expected result is more stable than asserting which private helper functions it calls.

Implementation-detail-heavy tests often break during harmless refactoring.

Use the narrowest useful level

If a pure function can prove the behavior, a full application integration test may be unnecessary.

If correctness depends on a database constraint or framework behavior, a mocked unit test may be insufficient.

Arrange, Act, Assert

A common test structure is:

1. Arrange input and dependencies

2. Act by executing behavior

3. Assert the outcome

This improves readability and makes failures easier to understand.

Edge cases

Test important boundaries such as:

The objective is not to maximize test count. It is to cover meaningful behavior with a balanced portfolio of fast unit tests and targeted integration tests.

Exceptions communicate exceptional failure conditions through the call stack.

Good debugging starts by preserving useful evidence rather than immediately suppressing the failure.

Raising exceptions

Use exceptions when an operation cannot fulfill its contract.

For example:

`python

if score < 0:

raise ValueError("score cannot be negative")

Choose exception types that communicate the nature of the failure.

Catching exceptions

Catch an exception when the current layer can do something useful, such as:

Avoid broad patterns such as:

`python

except Exception:

pass

because they can hide programming errors and destroy evidence.

Exception chaining

When translating an exception, preserve the original cause:

`python

try:

repository.load()

except DatabaseError as exc:

raise CandidateLoadError() from exc

This keeps causal information available in the traceback.

Tracebacks

A traceback shows the sequence of calls leading to an exception.

Read from the final exception outward while also examining the frames that belong to your application.

Do not focus only on the last line if the underlying cause began earlier.

Logging

Useful error logs can include:

Do not log passwords, access tokens, private keys, or unnecessarily sensitive payloads.

Use logger.exception() inside an exception handler when a traceback should be logged.

Debugger

Python includes the pdb debugger, and modern development environments often provide interactive debugging around the same runtime concepts.

Useful operations include:

The goal is to understand how program state reached the failure, not merely patch the line where the exception became visible.

Fail loudly during development

Silently converting unexpected exceptions into None, empty collections, or generic success values can make production debugging much harder.

Handle known failure modes intentionally and allow unexpected failures to remain observable.

Test doubles replace collaborators during tests so behavior can be controlled or observed.

Common forms include mocks, stubs, fakes, spies, and dummy objects.

Mocks

A mock can define return values, raise exceptions, and record interactions.

Python’s unittest.mock module provides tools such as Mock, MagicMock, and patch.

Mocks are useful when testing behavior that depends on an external collaborator but where the collaborator itself is not the subject of the test.

Patch where the dependency is looked up

One of the most common Python mocking errors is patching the original definition rather than the name actually used by the system under test.

If a module does:

`python

from payments import charge

and later calls charge(), the test normally patches the charge name in that importing module, not necessarily payments.charge.

Autospeccing

Mocks can become misleading if they allow methods or arguments that the real collaborator does not support.

Using autospec or a specification can constrain a mock to a real interface and catch some API drift.

Fakes

A fake is a lightweight working implementation, such as an in-memory repository.

Fakes can be easier to understand than large interaction-heavy mocks when behavior matters more than exact call counts.

Avoid mocking implementation details

A test that asserts every private helper call becomes tightly coupled to the current implementation.

Prefer verifying meaningful outputs, state transitions, or externally important collaborator calls.

Mocking does not prove integration

A mocked database client can confirm your code calls a method, but it cannot prove the SQL is valid or that the database schema matches.

Maintain integration tests for critical boundaries.

Side effects and failures

Mocks are useful for testing failure paths:

But simulated behavior should match realistic failure semantics.

The best test double is the simplest one that isolates the behavior without creating a fictional environment.

Large test suites often become difficult to maintain because test setup and data become more complex than the behavior being tested.

The solution is not simply more abstraction. Test setup should remain explicit and close to the behavior it supports.

Fixtures

A fixture establishes reusable test state or resources.

Examples include:

Fixtures should have clear scope and cleanup behavior.

A very large fixture that prepares the entire application for every test increases execution time and makes dependencies unclear.

Use builders or factories for complex data

When domain objects require many fields, small test-data builders or factory functions can make defaults explicit while allowing individual tests to override only relevant values.

Avoid one giant shared object mutated by many tests.

Parameterization

When the same behavior should hold for several input/output combinations, parameterization reduces repetitive test code.

For example, validation can be tested across several boundary values using one test body.

Even if the project uses a framework such as pytest for parameterization, the important concept is to represent repeated behavioral cases as data rather than duplicate large test functions.

Invariants

Some behavior is better expressed as a property that should hold over many valid inputs.

Examples include:

Property-based testing tools can generate many inputs to search for counterexamples to these invariants.

This complements example-based testing rather than replacing it.

Determinism

Randomized tests should preserve enough information to reproduce failures.

Tests should avoid dependence on:

Cleanup

Use context managers, fixture cleanup hooks, or temporary-resource APIs so failed tests do not leave state that corrupts later tests.

Readable failure messages

Parameterized and generated tests should identify which input failed so developers can reproduce and understand the problem quickly.

Test abstractions should reduce duplication while preserving visibility into the behavior under test.

Python packaging separates source code, project metadata, build configuration, dependency installation, and runtime environments.

A production project should make these relationships explicit.

pyproject.toml

Modern Python packaging uses pyproject.toml as a standard configuration point for build-system requirements and project metadata.

Metadata can include:

The exact supported fields and workflow depend on the packaging standards and selected build backend.

Virtual environments

A virtual environment isolates installed packages from the global interpreter environment.

Python provides the venv module:

`bash

python -m venv .venv

Isolation reduces conflicts between projects requiring different dependency versions.

A virtual environment is not a security sandbox. It primarily isolates Python package installation state.

Runtime versus development dependencies

Runtime dependencies are required for the application or library to operate.

Development dependencies may include:

Do not force library consumers to install development-only tooling as runtime dependencies.

Distributions

Common Python distribution artifacts include:

A wheel can often be installed without rebuilding the project from source, making installation faster and more predictable when a compatible wheel exists.

Version constraints

Dependency constraints should reflect compatibility requirements.

Overly loose dependencies can allow unexpected incompatible releases, while excessively restrictive constraints can prevent safe upgrades.

Applications often require stronger reproducibility controls than reusable libraries because applications deploy one complete environment.

Locking and reproducibility

The standard packaging ecosystem supports dependency declarations, but reproducible application environments often use an additional lock or resolved-dependency workflow provided by the selected package-management tooling.

The important requirement is that production builds resolve dependencies intentionally and repeatably.

Build isolation

Modern build frontends can build projects in isolated environments according to the requirements declared by the build system.

This reduces accidental dependency on packages installed globally on a developer machine.

Editable installs

Editable installations can be useful during development because source changes are reflected without repeatedly reinstalling the package.

Production deployment should use normal built artifacts rather than depending on development-oriented editable behavior.

A good packaging setup allows another developer or CI system to create a clean environment and build or install the project without relying on undocumented local state.

A large Python platform needs a quality strategy that produces fast developer feedback while still validating the boundaries most likely to fail in production.

The objective is to make ownership, dependencies, state changes, and business behavior easy to understand and test.

1. Define a test portfolio

Use several levels intentionally:

Keep the majority of routine feedback fast while ensuring critical boundaries are exercised realistically.

2. Establish test ownership

Tests belong with the code and service owners responsible for the behavior.

A central QA team should not become the only group capable of understanding why application tests fail.

Platform teams can provide frameworks, infrastructure, and standards while product teams retain outcome ownership.

3. Control flakiness

Track flaky tests explicitly.

Common causes include:

Do not normalize rerunning tests until they happen to pass.

A flaky test weakens trust in the entire pipeline.

4. Use realistic ephemeral dependencies

Critical integration tests should run against controlled versions of required infrastructure where practical.

Examples include:

The test environment should remain isolated and reproducible.

5. Define packaging and build standards

Every deployable Python service should have a reproducible process for:

Do not allow production artifacts to depend on packages installed manually on a build machine.

6. Promote immutable artifacts

Build once and promote the same artifact through environments where feasible.

Rebuilding separately for staging and production can introduce dependency or build differences unrelated to the tested code.

7. Establish dependency policy

Define how teams handle:

Dependencies should be updated deliberately rather than frozen indefinitely or accepted blindly.

8. Make failures observable

Production Python services should preserve:

Error handling should not erase diagnostic context.

9. Reproduce production failures

Incident investigation should aim to produce a minimal reproducible case or failing automated test when practical.

This turns a one-time production failure into a regression guard.

10. Use risk-based release gates

A documentation-only change may need fewer gates than a migration touching critical persistent data.

Possible gates include:

11. Keep debugging environments safe

Avoid copying raw sensitive production data into developer environments merely to reproduce an issue.

Prefer redacted datasets, synthetic reproductions, controlled snapshots, or narrowly authorized investigation procedures.

12. Measure quality-system health

Useful signals include:

The strongest quality platform makes correct practices easy while keeping teams accountable for the behavior they ship.

A Python web application sits between HTTP clients and application behavior.

Frameworks such as Django and FastAPI provide different APIs and conventions, but the major responsibilities are similar.

Request lifecycle

A typical request passes through stages such as:

1. HTTP server receives the connection

2. Framework matches the request to a route

3. Middleware may inspect or modify the request

4. Input is parsed and validated

5. Authentication and authorization rules are applied

6. Application or domain logic executes

7. Persistence or external integrations may be invoked

8. A response is serialized

9. Middleware may modify the response

10. HTTP server returns it to the client

Routing

Routing maps an HTTP method and path to application behavior.

Examples include:

Routes should describe transport-level behavior rather than contain every business rule directly.

Validation

Validate external data before allowing it to reach deeper application layers.

Typical validation includes:

Syntactic validation at the HTTP boundary does not replace business validation.

For example, a UUID can be structurally valid while still referencing an application the user is not allowed to modify.

Business logic

Core rules should normally live outside route handlers when they are substantial or reusable.

This improves:

Response handling

A route should map application outcomes to appropriate HTTP behavior.

Examples include:

Do not leak raw internal exceptions, database errors, or secrets to clients.

Dependency management

Database sessions, service clients, repositories, authentication context, and configuration should have explicit lifetimes.

Framework dependency mechanisms can help construct and clean up request-scoped resources.

The route should remain understandable as an HTTP boundary instead of becoming a large function that performs validation, SQL, business decisions, external calls, logging, and serialization itself.

A database transaction defines a unit of work whose changes should be treated consistently.

A common requirement is atomicity: either the required changes succeed together or the transaction is rolled back.

Why transactions matter

Suppose an application performs:

1. Create an application record

2. Update a tracking counter

3. Record an audit entry

If the first two operations commit but the third fails when all three are required for correctness, the database can be left in an inconsistent state.

A transaction allows the application to define the appropriate consistency boundary.

Commit

A commit makes the transaction’s successful changes durable according to the database system’s guarantees.

Commit after the complete logical unit of work succeeds.

Rollback

A rollback abandons changes in the current transaction when the operation cannot complete safely.

Exceptions should normally leave the transaction in a known state before the connection or session is reused.

Autocommit

Frameworks and database libraries differ in how transaction boundaries are exposed.

Django normally operates in autocommit mode unless a transaction is active and provides transaction.atomic() for explicit atomic blocks.

Django documentation recommends keeping transactions short because open transactions have a performance cost.

SQLAlchemy sessions similarly coordinate database work inside transactions and provide context-manager patterns for clearly framing begin, commit, rollback, and close behavior.

Keep transactions short

Avoid holding a database transaction open while performing unrelated slow operations such as:

Long transactions can hold locks, retain resources, increase contention, and make failures more costly.

Side effects and transactions

A database rollback cannot undo an email already sent or an external API call already accepted.

When external side effects depend on a successful database change, techniques such as after-commit callbacks or transactional-outbox patterns may be appropriate.

The transaction boundary should match the business consistency requirement instead of being automatically applied to every line in a request.

ORMs improve developer productivity, but they do not remove the need to understand SQL, transaction boundaries, connection usage, and query cost.

Session scope

An ORM session usually represents a unit of database interaction and transactional state.

SQLAlchemy documents Session as mutable and stateful and recommends a session per thread and an AsyncSession per asyncio task rather than sharing one session concurrently.

For web applications, request-scoped session patterns are common because they make ownership and cleanup explicit.

N+1 query problem

An N+1 problem occurs when code first queries a collection and then performs another query for each result.

Conceptually:

`python

jobs = load_jobs()

for job in jobs:

print(job.company.name)

If accessing company lazily issues one query per job, retrieving 100 jobs may cause 101 queries.

<!-- slide -->

Solutions depend on the ORM and relationship:

Do not apply eager loading blindly because retrieving huge relationship graphs can create excessive rows or memory use.

Inspect SQL

Developers should inspect generated queries rather than assuming ORM code is efficient.

Measure:

Avoid unnecessary round trips

Batch inserts or updates where appropriate and avoid querying the same unchanged record repeatedly in one operation.

Connection pools

Connection pools reuse database connections and limit how many connections the application uses concurrently.

SQLAlchemy describes pooling as the standard server-side pattern for maintaining reusable long-lived database connections.

Pool configuration must account for:

For example, 20 application processes each configured with 20 possible connections can theoretically pressure the database with hundreds of connections.

Do not hold connections unnecessarily

A request should not keep a database transaction or checked-out connection while it performs unrelated long-running work.

Indexes and ORM performance

An ORM cannot compensate for missing indexes or poor query design.

Use database execution plans and production-like data when investigating performance.

The objective is not to avoid ORMs. It is to use them while retaining an understanding of the database operations they generate.

An asynchronous route is useful only if the operations executed inside it cooperate with the asynchronous runtime.

Adding async def around blocking code does not make that code asynchronous.

Async-compatible operations

If a database driver, HTTP client, or other library exposes awaitable operations, an async route can await those operations while allowing other tasks to run.

FastAPI documentation explicitly distinguishes libraries that support await from blocking libraries that do not.

Blocking dependencies

A synchronous library may perform blocking network or file I/O.

Calling a long blocking operation directly on an event-loop thread can prevent unrelated async requests from progressing.

Depending on the framework and workload, options include:

Database session ownership

Do not share a single mutable database session across several concurrently executing tasks.

SQLAlchemy recommends one Session per thread and one AsyncSession per task.

A typical async web request therefore obtains its own session context and closes it after the request completes.

Bound concurrency

Async execution makes it easy to schedule many database or HTTP operations, but downstream resources remain finite.

Bound concurrency according to:

Transactions across awaits

Awaiting while a database transaction is active is not automatically wrong, but avoid holding transactions open across unrelated slow remote operations because locks and connections may remain occupied.

Structure operations so transaction lifetime matches the required consistency boundary.

CPU-intensive work

CPU-heavy operations can also block an event loop even when no network I/O is involved.

Move significant CPU work to suitable worker execution rather than performing it inline in a latency-sensitive async request.

The architecture should distinguish async I/O, blocking I/O, database transactional work, and CPU-heavy processing rather than treating all four as equivalent.

External services are independent distributed systems and should be treated as unreliable dependencies.

A correct integration needs more than sending an HTTP request and parsing JSON.

Timeouts

Every network operation should have explicit timeout or deadline behavior.

Consider separate limits for:

Without time limits, a dependency can consume application workers indefinitely.

Retries

Retries are appropriate only when the failure may be transient and repeating the operation is safe.

Possible retryable failures can include selected:

Do not blindly retry every client error or validation failure.

Backoff and jitter

Retrying immediately across many workers can amplify an outage.

Use bounded attempts with increasing delay and jitter where appropriate.

Idempotency

A timeout does not prove that the remote system failed to process a request.

For side-effecting operations such as payments or resource creation, repeating the request can produce duplicates.

Use an idempotency mechanism when supported or design local deduplication around a stable operation identifier.

Connection reuse

Reuse HTTP client sessions or connection pools where appropriate instead of establishing an entirely new transport connection for every request.

Scope clients to an appropriate application or worker lifecycle and close them cleanly.

Failure isolation

One degraded dependency should not consume all application capacity.

Use:

Validate responses

Do not assume a successful HTTP status means the payload satisfies your application contract.

Validate expected:

Observability

Record safe operational information such as:

Do not log authentication secrets or unnecessary personal data.

Graceful degradation

When possible, define whether the application can:

A resilient integration explicitly defines failure behavior rather than assuming dependencies are always healthy.

A production Python platform should make boundaries explicit so web traffic, database consistency, background processing, and third-party failures do not become one tightly coupled execution path.

1. Separate transport from application behavior

HTTP routes should handle concerns such as:

Application services should coordinate business use cases without depending unnecessarily on framework-specific request objects.

2. Model the domain independently

Keep important business rules in domain models or functions that can be tested without starting the web server or database.

Examples include:

3. Define persistence boundaries

Repositories or explicit data-access modules can isolate ORM and SQL behavior from business coordination where that separation provides value.

Do not create an abstraction merely to hide every ORM method. The boundary should protect actual architectural responsibilities.

4. Establish transaction ownership

A use case that modifies several related records should have one clearly owned transaction boundary.

Avoid allowing unrelated helper functions to commit independently because an outer operation can no longer guarantee atomicity.

SQLAlchemy sessions represent mutable transactional state, so each concurrent thread or async task should own an appropriate session rather than sharing one globally.

5. Keep transactions away from slow remote calls

Where possible:

1. Validate state

2. Perform required transactional database work

3. Commit

4. Trigger dependent external work safely

If an external side effect must be guaranteed after a database commit, use a durable pattern such as a transactional outbox rather than assuming an in-memory callback can never be lost.

6. Use durable background processing

Long-running or must-complete tasks should not rely exclusively on detached in-process tasks.

Examples include:

A durable queue allows retries and recovery after process restarts.

7. Design idempotent consumers

Queues and external systems can deliver operations more than once.

Use stable event or operation IDs, database uniqueness rules, or deduplication state so retries do not duplicate business effects.

8. Bound all concurrency

Define limits for:

SQLAlchemy connection pooling exists specifically to reuse and manage the number of active database connections; application-level worker counts must still respect total database capacity.

9. Choose sync versus async deliberately

Async web execution fits applications with substantial async-compatible I/O.

A primarily synchronous dependency stack can still be entirely appropriate.

FastAPI itself documents different handling depending on whether a third-party library exposes awaitable operations or blocking calls.

Do not migrate an application to async simply because async appears more scalable.

10. Protect dependency boundaries

Every external integration should define:

11. Provide observability

Correlate:

This makes cross-system failures diagnosable.

12. Scale based on bottlenecks

Adding API workers can increase pressure on the database or external APIs.

Scale the constrained resource rather than assuming horizontal application scaling fixes every bottleneck.

13. Preserve clean shutdown

A terminating process should:

14. Test failure paths

Integration and load testing should include:

The architecture is successful when failure remains bounded and understandable rather than cascading through the platform.