Forem: Rafał Fuchs

Transaction boundaries in Django: where consistency really ends

Rafał Fuchs — Fri, 17 Apr 2026 14:50:24 +0000

TL;DR: transaction.atomic() protects SQL work on one connection to one database. It does not protect queues, emails, webhooks, other databases, or third-party APIs. If you design a business process as if one atomic block covered the whole thing, sooner or later you will ship a half-commit to production: DB state changed, side effects missing (or the other way around). This post walks through where the real consistency boundary is, and what to reach for when you need more.

I'm a senior backend engineer working in Python/Django. More long-form writing at rafalfuchs.dev.

The illusion `atomic()` creates

Most Django developers learn transactions through a comforting pattern:

with transaction.atomic():
    order = Order.objects.create(...)
    Payment.objects.create(order=order, ...)
    send_confirmation_email(order)
    publish_to_kafka("order.created", order.id)

It reads like one unit of work. It feels atomic. It is not.

Only the first two lines are actually protected by the database transaction. The email and the Kafka publish happen inside the with block, but they are side effects that do not roll back if the transaction aborts. Worse: if they fire before the commit and the commit then fails, you just notified the world about an order that does not exist.

This is the core misconception I want to unpack: SQL commit is not business-process commit.

1. What `atomic()` actually guarantees

Think of atomic as a local database safety boundary. Scoped to one connection, one database, one transaction.

It does:

commit or roll back SQL changes together,
support nesting via savepoints,
preserve invariants inside that specific DB transaction.

It does not:

include external side effects (HTTP calls, emails, message brokers, cache writes),
guarantee delivery of any asynchronous message,
solve multi-database atomicity,
protect you from a successful commit followed by a crash before your handler returns.

That last point trips up a lot of people. The moment __exit__ on the context manager finishes, your transaction is committed. Anything afterwards is a new world, and the database has no idea whether your Celery task made it into Redis or not.

2. `ATOMIC_REQUESTS`: a sharp tool, not a default

ATOMIC_REQUESTS = True wraps every request in a transaction. It feels like a sane default, and for small apps it genuinely reduces accidental partial writes.

At higher traffic it starts to bite:

transactions live longer (the full request lifecycle, not just the write),
lock contention climbs on hot rows,
throughput on mixed read/write endpoints drops,
a slow external call inside a view now holds a DB transaction open for its entire duration.

The better architectural question is rarely "can we wrap the whole request?". It is "which specific write-critical section genuinely needs a transaction?". Reach for explicit with transaction.atomic(): around that section, and let the rest of the request run without holding row locks.

3. The minimum viable guardrail: `transaction.on_commit`

If you only take one pattern away from this post, take this one. Never fire a side effect from inside an atomic block directly. Register it with on_commit:

from django.db import transaction


def create_invoice_and_enqueue(invoice_data):
    with transaction.atomic():
        invoice = Invoice.objects.create(**invoice_data)

        transaction.on_commit(
            lambda: publish_invoice_created(invoice_id=invoice.id)
        )

    return invoice

on_commit holds the callback until the outermost transaction successfully commits. If the transaction rolls back, the callback never runs. No phantom notifications about invoices that no longer exist.

But note what this still does not give you:

if the process crashes between commit and on_commit execution, the callback is lost,
if the broker is down when the callback fires, the message is gone,
if the consumer processes the message twice, you get double side effects.

on_commit is a necessary guardrail, not a delivery guarantee. Pair it with retries on the producer side and idempotent consumers on the receiver side, or move to something stronger (see section 6).

4. Isolation levels and the race conditions you are not seeing

Django on PostgreSQL defaults to READ COMMITTED. That means: you see rows that were committed before your statement started. It does not mean: nobody can change a row between your SELECT and your UPDATE.

Classic broken pattern:

# BROKEN under concurrency
def reserve_stock(product_id, qty):
    with transaction.atomic():
        product = Product.objects.get(id=product_id)

        if product.available_qty < qty:
            raise ValueError("Insufficient stock")

        product.available_qty -= qty
        product.save(update_fields=["available_qty"])

Two concurrent requests both read available_qty = 5, both see enough stock for qty = 3, both subtract, and you have just oversold by 1 unit. The transaction committed successfully. The business invariant is broken.

Three tools to pick from, in rough order of cost:

4a. Pessimistic locking with `select_for_update`

from django.db import transaction


def reserve_stock(product_id, qty):
    with transaction.atomic():
        product = (
            Product.objects
            .select_for_update()
            .get(id=product_id)
        )

        if product.available_qty < qty:
            raise ValueError("Insufficient stock")

        product.available_qty -= qty
        product.save(update_fields=["available_qty"])

Simple, correct, and it serializes everyone hitting the same row. Use it for short critical sections on high-value state (stock, balance, seat booking). Keep the locked section small - do not put HTTP calls inside.

4b. Optimistic locking with a version column

updated = (
    Product.objects
    .filter(id=product_id, version=expected_version)
    .update(
        available_qty=F("available_qty") - qty,
        version=F("version") + 1,
    )
)

if updated == 0:
    raise ConcurrentUpdateError("retry")

Lets readers through without blocking. The loser of a race has to retry. Good fit for read-heavy paths where contention is rare but must be detected.

4c. Database constraints as the last line of defence

UNIQUE, CHECK, FK, partial indexes. Your application logic will have bugs. The database is the one layer that will reliably catch a duplicate order number or a negative balance. Treat constraints as non-negotiable, not as "optimization for later".

5. The moment you cross a process boundary, there is no global transaction

The moment your use case touches Celery, a webhook, an email provider, a second database, or any external API, you are out of the ACID world. There is no protocol that wraps "insert row in Postgres" and "send message to SQS" into one atomic action. Two-phase commit exists on paper. Almost nobody runs it in production for good reasons.

What you actually have is a distributed system with partial failures. Your options:

Scenario	Acceptable approach
Side effect is nice-to-have (analytics event)	`on_commit` + fire-and-forget, accept occasional loss
Side effect must eventually happen	`on_commit` + retries + idempotent consumer
Side effect must happen exactly-once-ish, and loss is unacceptable	Outbox pattern

The outbox pattern is the one I reach for in anything touching billing, inventory, compliance, or audit.

6. The outbox pattern, concretely

The idea: instead of publishing to a broker from application code, write the message to a regular table in the same transaction as your domain change. A separate worker reads the outbox and publishes. Because the write and the message land in one DB commit, they succeed or fail together.

Schema

class OutboxEvent(models.Model):
    id = models.BigAutoField(primary_key=True)
    aggregate_type = models.CharField(max_length=64)
    aggregate_id = models.CharField(max_length=64)
    event_type = models.CharField(max_length=128)
    payload = models.JSONField()
    created_at = models.DateTimeField(auto_now_add=True)
    published_at = models.DateTimeField(null=True, db_index=True)

    class Meta:
        indexes = [
            models.Index(
                fields=["published_at", "id"],
                name="outbox_unpublished_idx",
                condition=models.Q(published_at__isnull=True),
            ),
        ]

Writing the event

from django.db import transaction


def create_invoice(invoice_data):
    with transaction.atomic():
        invoice = Invoice.objects.create(**invoice_data)

        OutboxEvent.objects.create(
            aggregate_type="invoice",
            aggregate_id=str(invoice.id),
            event_type="invoice.created",
            payload={"id": invoice.id, "total": str(invoice.total)},
        )

    return invoice

No on_commit, no direct broker call. The invoice row and the outbox row commit together, or neither exists.

Relaying

A separate process (Celery beat, a small dedicated worker, or a CDC tool like Debezium reading the WAL) pulls unpublished rows and publishes them:

from django.db import transaction
from django.utils import timezone


def relay_outbox(batch_size=100):
    with transaction.atomic():
        events = (
            OutboxEvent.objects
            .select_for_update(skip_locked=True)
            .filter(published_at__isnull=True)
            .order_by("id")[:batch_size]
        )

        for event in events:
            publish_to_broker(
                topic=event.event_type,
                key=event.aggregate_id,
                payload=event.payload,
                message_id=str(event.id),   # for consumer dedup
            )
            event.published_at = timezone.now()
            event.save(update_fields=["published_at"])

skip_locked lets you run multiple relay workers without them fighting over the same rows.

What you gain

no lost events on broker outage (they sit in the outbox),
no phantom events on rollback (they never hit the outbox),
an auditable history of what was published and when,
a lag metric (unpublished outbox rows and oldest unpublished row age) you can alert on.

What you still owe the consumer side

Consumers must be idempotent. Design every handler so that receiving the same message twice is a no-op. The outbox gives you at-least-once delivery, not exactly-once. The message ID (outbox row PK) is your dedup key.

7. Multiple databases: there is no `atomic` across them

Django supports multiple databases. It does not give you a cross-database transaction. This code is a lie:

# Does NOT make the two writes atomic
with transaction.atomic(using="default"):
    with transaction.atomic(using="analytics"):
        Order.objects.using("default").create(...)
        AnalyticsEvent.objects.using("analytics").create(...)

If the default commit succeeds and the analytics commit fails (or the process dies in between), you have inconsistent state across databases with no automatic recovery.

Practical rules:

keep each business invariant anchored in one database,
if a flow genuinely spans databases, design it as eventual consistency: commit to the source of truth, then propagate via outbox or CDC,
accept that "propagate" means "retry forever until it sticks, with alerts if lag grows".

8. Decision matrix

Pattern	Use when	Avoid when
Plain `atomic`	Single DB write, no external side effects, low business risk	Any side effect leaves the DB
`atomic` + `on_commit`	Side effects must run after commit, brief loss is acceptable, basic retry in place	Loss is genuinely unacceptable
Outbox + idempotent consumers	Billing, inventory, compliance, audit, anything where partial failure is a incident	You have no consumers and never will
Saga / compensation	Long-running workflows across multiple services	Simple CRUD

Do not jump to the bottom of the table by default. Outbox has operational cost: another table, another worker, another dashboard, another runbook. Use it where the business cost of a lost event exceeds that.

9. Production checklist

Before you ship any write path that has side effects, walk through this:

Is every critical write anchored in a single database?
Are all external side effects deferred until after commit (either via on_commit or outbox)?
Are all message consumers idempotent? Do you have a dedup strategy with a concrete key?
Do you track outbox lag (oldest unpublished row age) and retry rate, with alerts?
Do your integration tests include concurrent writers hitting the same row?
Is there a runbook for recovery from a half-commit? Who runs it at 03:00?
Do you have constraints in the DB that catch the failure modes your application logic might miss?
Are long-running operations (HTTP, file I/O) kept out of atomic blocks?

If any answer is "we will add it later", that is the thing that will page you.

Final verdict

transaction.atomic() gives you local transactional correctness inside one database. It does not give you global process consistency. Those are different layers, solved by different tools.

Most "committed but broken" production incidents come from conflating them - trusting one with transaction.atomic(): block to cover a process that actually spans three systems. Treat the database transaction as one small, strict boundary, move every side effect to on_commit at minimum, and reach for the outbox pattern when losing an event is unacceptable.

Get that separation right and a whole class of weird half-state bugs disappears from your backlog.

If this was useful, I write more about Django architecture, backend design, and production consistency at rafalfuchs.dev/en/blog. The original version of this post lives here.

SEO Is Not Enough. What AIO (Generative Engine Optimization) Is and Why Your Company Needs It in 2026

Rafał Fuchs — Thu, 09 Apr 2026 18:59:28 +0000

SEO Is Not Enough. What AIO (Generative Engine Optimization) Is and Why Your Company Needs It in 2026

Google CTR is falling as more users consume answers without clicking. This guide explains AIO/GEO vs SEO and how to prepare your company for visibility in ChatGPT and AI assistants.

The Decision Problem: Is SEO Alone Still Enough in 2026?

If your growth strategy still assumes that winning means getting the click from Google, you are operating on a distribution model built for the previous decade.

In 2026, a growing share of user intent gets consumed inside answer interfaces:

Google AI Overviews
ChatGPT Search
Perplexity
Claude
Gemini

Users get a synthesis and recommendations before they even decide whether to open a link.

SEO is not dead. But SEO alone is no longer a complete solution.

What Changed in Practice (and Why CTR Is Falling)

This is not just a UI refresh. The information consumption model is changing.

In July 2025, Pew Research Center reported that when users see an AI summary in Google, they are less likely to click traditional results and more likely to end the session without visiting a website.

At the same time, OpenAI expanded ChatGPT Search as a full search interface, making it broadly available on February 5, 2025.

Operational Conclusion

A portion of traffic and purchase decision-making is shifting from:

“click a result” →
“ask an assistant and choose a recommendation”

SEO vs AIO/GEO: The Architectural Difference

SEO optimizes for indexing, ranking, and clicks.

AIO/GEO optimizes for how models understand and use your data in answers.

Key Difference

SEO → How do we rank higher in SERP?
AIO/GEO → How do we ensure AI reconstructs our offer correctly and recommends us?

In the AI layer, the winner is not always the highest-ranking website—but the one with the clearest semantic structure.

Why Classic SEO Underperforms in Generative Search

Modern websites are optimized for humans and front-end frameworks—not for machine understanding.

For AI models:

Heavy HTML = harder parsing
Dynamic rendering = inconsistent context
Weak relationships = ambiguity

What AI Actually Needs to Answer

What exactly do you sell?
Who is it for?
What are your packages or pricing?
What proves your credibility?
When should someone choose you (and when not)?

SEO answers this indirectly.

AIO/GEO answers this directly.

What AIO/GEO Looks Like in Practice

AIO/GEO is best understood as a data and knowledge distribution layer.

It’s not about more content—it’s about better structured information.

Core Layers

Semantic layer (JSON-LD, Schema.org)
LLM reference layer (llms.txt, extended files)
AI crawler accessibility layer
Observability layer

This makes AIO/GEO an architectural decision, not a content task.

How It Works Under the Hood

1. JSON-LD + Schema.org: Stop Forcing AI to Guess

Without structured data, AI guesses meaning.

With structured data, AI understands relationships:

who
what
for whom
where
under what conditions

This is why AIO starts with a semantic audit, not more blog posts.

2. llms.txt and llms-full.txt: Reference Layer

llms.txt acts as a knowledge capsule for AI systems.

Important:

It’s an emerging convention—not a strict standard like robots.txt.

Extended approach:

llms.txt → summary
llms-full.txt → full structured context

Best used when:

your frontend is heavy
business context is hard to extract

3. AI Crawler Accessibility

AIO fails if bots cannot read your content.

Must Be Verified

robots.txt for:
- OAI-SearchBot
- GPTBot
- ClaudeBot
- PerplexityBot
rendering consistency
metadata (Open Graph, titles, descriptions)
response times

This is baseline infrastructure, not optional.

4. Observability: Does AI Understand You?

Core problem:

You don’t know how AI sees your company.

Solution:

simulate buying-intent prompts
analyze answers
measure visibility

This turns assumptions into measurable data.

Where AIO/GEO Delivers the Highest ROI

Best results appear in decision-stage queries.

High-Impact Segments

B2B SaaS
Expert services / clinics
Local high-ticket services
Niche solutions
Companies with rising CAC from ads

If users ask AI “what should I choose?” → AIO becomes critical.

Trade-Offs: What AIO/GEO Won’t Fix

AIO/GEO will NOT fix:

weak offer
lack of proof
unclear positioning
inconsistent messaging

It improves representation, not business fundamentals.

Second limitation:

no monitoring = lost visibility over time

How to Roll It Out (Without Rebuilding Everything)

You don’t need a full rebuild.

Practical Plan

Run an AI visibility audit
Fix semantic structure
Add reference layer
Verify crawler access
Monitor and iterate (2–4 weeks cycles)

👉 Start here: AiVisible Audit

Where AiVisible Fits

AiVisible focuses on visibility in AI-generated answers, not just rankings.

What It Includes

AI interpretation audit
semantic mapping of your offer
plug-and-play implementation
missed-query analysis
iteration plan based on real prompts

👉 Try: AiVisible Audit

The value is not just traffic—it’s being recommended at decision moment.

How to Measure AIO/GEO Impact

SEO metrics are not enough.

Better Metrics

brand share in AI answers
correctness of descriptions
missed queries vs competitors
time to first recommendation
lead quality from AI channels

Conclusion

SEO is not gone—but it’s no longer the only growth system.

Winners Optimize Both

SEO → indexing & ranking
AIO/GEO → understanding & recommendation

This is a shift in how the web delivers answers.

Final Challenge

Your old SEO will not win here.

Find out how ChatGPT perceives your company today:

👉 AiVisible Audit

A Complete Guide to Django Performance Optimization

Rafał Fuchs — Thu, 09 Apr 2026 18:56:07 +0000

A Senior-Level Guide to Optimizing Django Applications

A practical, production-focused guide covering ORM pitfalls, SQL performance, caching, API design, architecture, and real-world scaling decisions.

Introduction

Optimizing a Django application is something every production system eventually faces. Early on, everything feels fast. As users grow, data expands, and business logic becomes more complex, bottlenecks inevitably appear.

This guide is based on real production issues, code audits, and hands-on experience with systems handling hundreds of thousands of requests per day.

How to Think About Django Optimization

The most common mistake: optimizing blindly.

Django is a high-level framework. Most performance issues don’t come from Django itself, but from architectural decisions.

Before touching the code, answer:

Where exactly is time being lost?
Is the problem:
- CPU-bound
- Database-bound
- I/O-bound
Is the issue constant or dependent on data size?

Rule of thumb: Never optimize anything you haven’t measured.

Application Profiling

Without profiling, optimization is guesswork.

Common Tools

Django Debug Toolbar (local)
django-silk / debug toolbar on staging
SQL query logging
APM tools:
- New Relic
- Datadog
- Sentry Performance

What to Measure

Number of SQL queries per request
Execution time of queries
Serialization time
View rendering time

ORM and SQL Query Optimization

Django ORM is powerful—but easy to misuse.

Eliminating the N+1 Problem

Classic issue in Django apps.

Symptoms

Looping over objects
Each related object access triggers a query

Solutions

select_related() → ForeignKey / OneToOne
prefetch_related() → ManyToMany / reverse FK
Prefetch() with custom querysets

Rule: Any query inside a loop = performance bug.

Limiting Retrieved Data

Model.objects.all() is often excessive.

Techniques

only() / defer() for wide models
Explicit fields in serializers
Separate lightweight read models

Benefits

Faster serialization
Lower memory usage
Reduced latency

Database Indexes

Missing indexes = silent performance killers.

Focus On

Fields in filter()
Fields in order_by()
Fields used in joins

Decision Rules

Query runs multiple times per second → add index
Table > 100k rows → regular index audits

Cache as an Architectural Component

Cache is not an add-on. It’s part of system design.

View-Level Cache

Best for:

Public endpoints
Rarely changing data
Dashboards / reports

Tools

cache_page
Reverse proxies (Varnish, CDN)

Data-Level Cache

Most flexible approach.

Examples

Query results
Aggregations
Expensive computations

Good Practices

Keys based on business parameters
Short TTL + manual invalidation
Redis as production standard

API and Serialization Optimization

APIs often become bottlenecks faster than the database.

Common Problems

Deep serialization trees
“Universal” serializers
No pagination

Solutions

Separate serializers (list vs detail)
Use SerializerMethodField sparingly
Always paginate collections

Rule: Unpaginated endpoints = bug.

Asynchronous Processing and Background Tasks

Not everything belongs in request–response.

Good Async Candidates

Emails
Report generation
External API integrations
Heavy validation

Typical Stack

Celery + Redis / RabbitMQ
Django Q

Requirements

Idempotency
Retry-safe logic

Application Architecture and Performance

Performance often loses to “clean-looking code”.

Common Issues

Fat models
Business logic in serializers
No read/write separation

Better Patterns

Service layer
CQRS (for larger systems)
Read models optimized for use cases

Scaling Django

Django scales well—if designed properly.

Key Elements

Stateless backend
Shared cache (Redis)
Shared storage (S3, GCS)
Load balancers

Decision Rules

More users → horizontal scaling
Slower queries → optimize data, not hardware

When Django Is No Longer Enough

Rare—but possible.

Warning Signs

Ultra-low latency (<50 ms)
Heavy real-time workloads
CPU-heavy request processing

Strategy

Extract critical components
Use microservices only where justified
Keep Django as business core

Summary

Django optimization is a process, not a one-time task.

Core Principles

Measure before optimizing
Treat ORM as a tool—not magic
Cache is foundational
Architecture > micro-optimizations

A well-designed Django application can handle large-scale systems without changing the technology stack.

If you found this useful, you can read the full canonical version here:

django performace optimization

Forem: Rafał Fuchs

Transaction boundaries in Django: where consistency really ends

The illusion atomic() creates

1. What atomic() actually guarantees

2. ATOMIC_REQUESTS: a sharp tool, not a default

3. The minimum viable guardrail: transaction.on_commit

4. Isolation levels and the race conditions you are not seeing

4a. Pessimistic locking with select_for_update

4b. Optimistic locking with a version column

4c. Database constraints as the last line of defence

5. The moment you cross a process boundary, there is no global transaction

6. The outbox pattern, concretely

Schema

Writing the event

Relaying

What you gain

What you still owe the consumer side

7. Multiple databases: there is no atomic across them

8. Decision matrix

9. Production checklist

Final verdict

SEO Is Not Enough. What AIO (Generative Engine Optimization) Is and Why Your Company Needs It in 2026

SEO Is Not Enough. What AIO (Generative Engine Optimization) Is and Why Your Company Needs It in 2026

The Decision Problem: Is SEO Alone Still Enough in 2026?

What Changed in Practice (and Why CTR Is Falling)

Operational Conclusion

SEO vs AIO/GEO: The Architectural Difference

Key Difference

Why Classic SEO Underperforms in Generative Search

What AI Actually Needs to Answer

What AIO/GEO Looks Like in Practice

Core Layers

How It Works Under the Hood

1. JSON-LD + Schema.org: Stop Forcing AI to Guess

2. llms.txt and llms-full.txt: Reference Layer

3. AI Crawler Accessibility

Must Be Verified

4. Observability: Does AI Understand You?

Where AIO/GEO Delivers the Highest ROI

High-Impact Segments

Trade-Offs: What AIO/GEO Won’t Fix

How to Roll It Out (Without Rebuilding Everything)

Practical Plan

Where AiVisible Fits

What It Includes

How to Measure AIO/GEO Impact

Better Metrics

Conclusion

Winners Optimize Both

Final Challenge

A Complete Guide to Django Performance Optimization

A Senior-Level Guide to Optimizing Django Applications

Introduction

How to Think About Django Optimization

Application Profiling

Common Tools

What to Measure

ORM and SQL Query Optimization

Eliminating the N+1 Problem

Symptoms

Solutions

Limiting Retrieved Data

Techniques

Benefits

Database Indexes

Focus On

Decision Rules

Cache as an Architectural Component

View-Level Cache

Tools

Data-Level Cache

Examples

Good Practices

API and Serialization Optimization

Common Problems

Solutions

Asynchronous Processing and Background Tasks

Good Async Candidates

Typical Stack

Requirements

The illusion `atomic()` creates

1. What `atomic()` actually guarantees

2. `ATOMIC_REQUESTS`: a sharp tool, not a default

3. The minimum viable guardrail: `transaction.on_commit`

4a. Pessimistic locking with `select_for_update`

7. Multiple databases: there is no `atomic` across them