Question 1

How does FastAPI handle async vs sync endpoints?

Accepted Answer

FastAPI is built on Starlette and uses Python's `asyncio` event loop via Uvicorn (or Hypercorn) as the ASGI server. How it handles async vs sync endpoints has significant performance implications.

**Async endpoints (`async def`):**

Async endpoints run directly in the event loop on the main thread. When an async endpoint awaits an I/O operation (database query, HTTP call), it yields control back to the event loop, which can process other requests. This allows thousands of concurrent requests with a single process — the classic async I/O benefit.

```python
@app.get('/items/{id}')
async def get_item(id: int):
    item = await db.fetch_one(query, values={'id': id})  # yields to event loop
    return item
```

Critical rule: **you must never block the event loop in an async endpoint.** Calling synchronous blocking code (`time.sleep`, synchronous `requests.get`, `psycopg2` queries) in an async context freezes the entire server — no other requests can be processed until the blocking call returns.

**Sync endpoints (`def`):**

FastAPI detects that an endpoint is defined with `def` (not `async def`) and automatically runs it in a **threadpool** using `asyncio.run_in_executor` (backed by `concurrent.futures.ThreadPoolExecutor`). This prevents blocking the event loop.

```python
@app.get('/items/{id}')
def get_item(id: int):
    item = db.execute(query)  # sync blocking — safe because it runs in threadpool
    return item
```

The default threadpool has 40 threads (Starlette default). Each sync endpoint occupies one thread for the duration of the call. Under high concurrency, thread pool exhaustion becomes the bottleneck.

**The dangerous case:** An `async def` endpoint that calls synchronous blocking code. FastAPI cannot detect this and will not move it to a threadpool. The blocking call runs in the event loop and stalls all concurrent requests.

**Practical guidance:**
- Use `async def` with an async database driver (asyncpg, databases, SQLAlchemy async) for I/O-bound work
- Use `def` with synchronous drivers (psycopg2, SQLAlchemy synchronous) — FastAPI handles threadpool dispatch
- Use `asyncio.get_event_loop().run_in_executor(None, cpu_bound_func)` or a process pool for CPU-bound work — never block the event loop with CPU work in an async endpoint
- FastAPI's dependency injection respects this — async dependencies in async endpoints, sync dependencies in sync endpoints (though mixing is supported with limitations)

Question 2

What are Django signals and when should you use them?

Accepted Answer

Django's signal framework is a publish-subscribe mechanism that allows decoupled components to react to events elsewhere in the codebase. The core classes are `Signal`, `receiver`, and `connect`.

The built-in signals cover the ORM lifecycle (`pre_save`, `post_save`, `pre_delete`, `post_delete`, `m2m_changed`), request/response cycle (`request_started`, `request_finished`), and migrations. You can define custom signals for your own events.

Basic usage:

```python
from django.db.models.signals import post_save
from django.dispatch import receiver
from myapp.models import User
from notifications.tasks import send_welcome_email

@receiver(post_save, sender=User)
def on_user_created(sender, instance, created, **kwargs):
    if created:
        send_welcome_email.delay(instance.id)
```

**When signals are appropriate:**
- Reactions in a different Django app to events in another app, where directly importing the other app would create a circular dependency
- Pluggable, reusable apps that shouldn't know about the host project's behavior (e.g., `django-allauth` hooks)
- Framework-level cross-cutting concerns: audit logging, cache invalidation that spans multiple apps

**When signals are a code smell:**
- When sender and receiver are in the same app — a direct function call is clearer, easier to test, and shows up in stack traces
- When you need transactional guarantees — `post_save` fires after the ORM save but still within the open transaction if called from within `atomic()`. However, signal handlers are not automatically wrapped, and failures in handlers don't roll back the triggering transaction unless you handle exceptions explicitly
- When you need to test in isolation — signals make code harder to follow (the call graph is invisible) and harder to unit test

**Pitfalls:**
- Receivers are registered globally. If your `apps.py` ready() method registers a receiver (the recommended way), double-registering by also importing the module directly creates duplicate calls
- Use `dispatch_uid` to prevent duplicate registration: `@receiver(post_save, sender=User, dispatch_uid='myapp.on_user_created')`
- Signals are synchronous and blocking. Don't do heavy work in a signal handler — push to a task queue (Celery) instead
- `post_save` does not fire on `bulk_create` or `QuerySet.update()` — common source of bugs

The Django docs themselves note that signals are often overused. Direct method calls, service objects, or explicit hooks are preferable when the coupling is intentional.

Question 3

What is the difference between select_related and prefetch_related in Django?

Accepted Answer

Both methods solve the N+1 query problem in Django, but they work differently and apply to different relationship types. Choosing the wrong one still causes N+1 or unexpected query counts.

**`select_related`** performs a SQL JOIN. It fetches the related objects in a single query by joining the related table. It only works for **ForeignKey** and **OneToOne** relationships (relations that follow a single join path). It is depth-unlimited but each level adds a JOIN.

```python
# Without select_related: 1 + N queries
orders = Order.objects.all()
for order in orders:  # N queries for order.customer
    print(order.customer.name)

# With select_related: 1 query with JOIN
orders = Order.objects.select_related('customer').all()
```

Generated SQL: `SELECT order.*, customer.* FROM order INNER JOIN customer ON order.customer_id = customer.id`

`select_related('customer__address')` traverses multiple levels with chained JOINs.

**`prefetch_related`** executes separate queries — one per relationship — and performs the join in Python. It handles **ManyToMany**, **reverse ForeignKey** (accessing the many side of a FK relation), and GenericRelatedObjectManager. It can also handle ForeignKey/OneToOne, but `select_related` is more efficient for those.

```python
# Fetches authors, then a separate query for all books of those authors
authors = Author.objects.prefetch_related('book_set').all()
for author in authors:
    for book in author.book_set.all():  # uses prefetch cache, no extra query
        print(book.title)
```

Generated SQL: Query 1: `SELECT * FROM author`; Query 2: `SELECT * FROM book WHERE author_id IN (1, 2, 3, ...)`

**`Prefetch` object with custom querysets:** `prefetch_related(Prefetch('book_set', queryset=Book.objects.filter(published=True)))` — lets you apply filters, ordering, or annotations to the prefetched queryset. Critical when you need a subset of related objects.

**Common mistakes:**
- Using `select_related` on a ManyToMany — it doesn't work; use `prefetch_related`
- Calling `.filter()` on a prefetched relation in a loop — this invalidates the cache and causes N+1 again. Use `Prefetch()` with the filter applied in advance
- Not using either — relying on Django's lazy evaluation in templates where the N+1 is invisible

Use `django-debug-toolbar` or `django.db.connection.queries` to verify query count.

Question 4

How does the SQLAlchemy session work?

Accepted Answer

The SQLAlchemy Session is the core of the ORM's unit-of-work pattern. Understanding it prevents the most common bugs: detached instance errors, unexpected autoflush, and transaction leaks.

**Unit of Work**

The Session acts as a transaction-scoped identity map and change tracker. When you add objects to the session or query objects through it, they enter the **identity map** — a dict keyed by primary key. The identity map guarantees that within a session, loading the same row twice gives you the same Python object, not two separate instances.

The session tracks each object's state:
- **Transient:** created with `MyClass()` but not yet added to a session
- **Pending:** added via `session.add()` but not yet flushed to the DB
- **Persistent:** in the session and has a corresponding row in the DB (either just inserted via flush, or loaded via query)
- **Detached:** was persistent, then the session was closed or the object was expunged. Database identity exists but no session tracks it. Accessing lazy-loaded relationships raises `DetachedInstanceError`.

**Flush vs Commit**

`session.flush()` writes pending changes to the database as SQL (INSERTs, UPDATEs, DELETEs) within the current transaction, but does not commit. The changes are visible within the same transaction but not to other transactions. SQLAlchemy autoflushes by default before queries to ensure the query sees current state.

`session.commit()` flushes and then commits the transaction. After commit, persistent objects are expired — their attributes will be lazily reloaded on next access.

`session.rollback()` reverts the transaction and expires all objects.

**Scoped Sessions**

In web applications, each request should have its own session. The `scoped_session` factory creates a registry that returns the same session object within the same thread (using thread-local storage by default). In async applications, use `AsyncSession` with `async_scoped_session` keyed on the async task.

The correct pattern with FastAPI:
```python
async def get_db():
    async with AsyncSessionLocal() as session:
        yield session
        # session.close() called automatically
```

**Common pitfalls:**
- Accessing lazy-loaded attributes after the session is closed: use `joinedload` or `selectinload` eagerly, or access within the session scope
- Long-lived sessions in background jobs accumulate stale state — call `session.expire_all()` or use short-lived sessions
- Not committing or rolling back on exception — use `try/except/finally` or a context manager
- Autoflush firing at unexpected times — SQL triggered by a query when you expected no DB activity

Question 5

How does Django middleware work?

Accepted Answer

Django middleware is a framework of hooks that sits between the WSGI/ASGI server and your view layer. Every HTTP request passes through each active middleware in order before reaching the view, and the response passes back through them in reverse order. This gives you a clean place to implement cross-cutting concerns — authentication, logging, session handling, CSRF protection — without polluting view code.

Middleware is configured in `settings.MIDDLEWARE` as an ordered list of dotted-path strings. Order matters: a middleware earlier in the list wraps all subsequent ones, so `SecurityMiddleware` must come first to enforce HTTPS redirects before anything else runs.

A middleware class implements up to five hook methods. `__init__(self, get_response)` is called once at server startup and receives a callable representing the rest of the middleware chain. `__call__(self, request)` is invoked on every request — you call `self.get_response(request)` to pass control downstream and get a response back, allowing you to modify both sides. The optional `process_view(request, view_func, view_args, view_kwargs)` hook fires after URL resolution but before the view executes, which is where CSRF validation happens. `process_exception(request, exception)` fires if the view raises. `process_template_response(request, response)` fires if the response has a `render()` method.

Django 1.10 introduced the new-style "callable" middleware, replacing the older class-based hooks (`process_request`, `process_response`). The callable style is cleaner because the entire request-response cycle is visible in one `__call__` method rather than split across two methods.

Practical example: a request-timing middleware wraps `get_response` with `time.perf_counter()` calls and appends a `X-Request-Duration` header to every response. Because it lives outside the view, it captures database and template rendering time too.

For async Django (ASGI), middleware must declare `async_capable = True` and implement `async def __call__`. Mixing sync and async middleware in the stack forces Django to run thread-pool adapters, which adds overhead — keep the stack homogeneous when running async workloads.

Common built-in middleware: `SecurityMiddleware` (HTTPS, HSTS, content-type sniffing), `SessionMiddleware`, `AuthenticationMiddleware` (depends on `SessionMiddleware` being earlier), `CsrfViewMiddleware`, `MessageMiddleware`.

Question 6

How does FastAPI use Pydantic for validation?

Accepted Answer

FastAPI integrates Pydantic deeply: any function parameter annotated with a Pydantic `BaseModel` subclass is treated as the request body. FastAPI deserializes the incoming JSON, instantiates the model (running all validators), and injects the validated instance into the handler. If validation fails, FastAPI returns a structured 422 Unprocessable Entity response automatically — no manual error handling needed.

**Request body validation** is the core use case. Define a model:

```python
class CreateUser(BaseModel):
    name: str
    age: int = Field(gt=0, lt=150)
    email: EmailStr
```

Declare it in the route: `async def create(user: CreateUser)`. FastAPI reads the JSON body, validates types, runs Field constraints (gt, lt, min_length, regex, etc.), and passes a fully typed object to the handler.

**Path and query parameters** use type annotations directly on function parameters — FastAPI infers whether they are path params (matching URL template), query params (everything else scalar), or body (BaseModel). Pydantic coerces string query params to declared types automatically.

**Response models** are declared via `response_model=UserOut` on the route decorator. FastAPI serializes the return value through the Pydantic model, filtering out fields not declared in `UserOut`. This prevents accidental data leakage — a route returning a `User` ORM object will not expose `hashed_password` if it is not in `UserOut`.

**Pydantic v2 changes** (FastAPI 0.100+): validators use `@model_validator` and `@field_validator` instead of v1's `@validator`. v2 is significantly faster (Rust core) and stricter about coercion by default.

**Dependency injection** works alongside Pydantic: `Depends()` lets you extract and validate common parameters (auth tokens, pagination) across routes without repeating logic.

The end result: the OpenAPI schema (available at `/docs`) is auto-generated from these Pydantic models, so documentation, validation, and serialization all stay in sync with the same source of truth — the type annotations.

Question 7

How does SQLAlchemy's connection pool work?

Accepted Answer

SQLAlchemy manages database connections through a connection pool that reuses existing connections rather than opening a new one per query—connection establishment (TCP handshake, TLS, authentication) is expensive and adds 10-100ms per request.

**Pool types**: SQLAlchemy provides several pool implementations. `QueuePool` (the default for most dialects) maintains a fixed pool of persistent connections with an overflow allowance. `NullPool` disables pooling—a new connection is created and closed for every operation, appropriate for serverless or short-lived processes where connections would be leaked. `StaticPool` uses a single connection for all requests, suitable for in-memory SQLite in tests. `AsyncAdaptedQueuePool` is the async equivalent for SQLAlchemy 2.x with `asyncpg` or `aiopg`.

**Connection lifecycle**: When code calls `engine.connect()` or begins a session, SQLAlchemy checks out a connection from the pool. The connection is returned to the pool (checked in) when the context manager exits (`with session:`, `with conn:`) or `session.close()` is called. If `close()` is never called (leaked connection), the pool slot is occupied until timeout. This is a critical bug pattern in web applications.

**Key configuration parameters**:
- `pool_size` (default 5): Number of persistent connections maintained.
- `max_overflow` (default 10): Additional connections allowed beyond `pool_size` during peak load. Total max connections = `pool_size + max_overflow`.
- `pool_timeout` (default 30s): How long a `connect()` call waits for a pool slot before raising `TimeoutError`.
- `pool_recycle` (default -1): Maximum age in seconds before a connection is replaced. Set to < MySQL's `wait_timeout` (8 hours default) to prevent 'MySQL server has gone away' errors on long-lived processes.
- `pool_pre_ping` (recommended: True): Before handing out a connection, SQLAlchemy sends a lightweight ping (`SELECT 1`). If the connection is stale (server restarted, firewall idle timeout), it is discarded and a new one checked out. Eliminates stale connection errors in production.

**Sizing the pool**: A common formula is `(core_count * 2) + effective_spindle_count`, but in practice, pool size should not exceed the database's `max_connections` divided by the number of application instances. Over-pooling causes the database to spend resources managing connections rather than executing queries.

**Connection leaks**: Always use context managers. In async code, ensure `await session.close()` is in a `finally` block or use `async with`. Enable pool logging (`echo_pool=True`) to detect leaks in staging.

Frameworks Interview Questions — What Senior Engineers Need to Know

All 7 Questions

How to Prepare

Related Topics

Test Your Knowledge