DEV Community: Acel

From O(N ) to O(1): Scaling M2M Validation in Django

Acel — Fri, 24 Jul 2026 06:00:00 +0000

Adding a few cities to a delivery zone is instant. Adding 5,000 cities ran over 5,000 database round-trips and regularly timed out the request. The root causes were two common Django patterns that don't scale: validating with per-row .exists() calls, and writing Many-to-Many relations with .add(). Here's the replacement.

The Problem

A shipping group links a set of cities to a delivery zone. The model is straightforward:

class ShippingGroup(models.Model):
    name = models.CharField(max_length=255)
    country = models.ForeignKey(Country, on_delete=models.CASCADE)
    cities = models.ManyToManyField(City)

When an admin creates a new shipping group, the endpoint needs to validate that none of the selected cities already belong to a competing group in the same region. The original code did this with a triple-nested loop:

for storefront in storefronts:
    for state in states:
        for city in cities:
            if ShippingGroup.objects.filter(
                company=self.company, storefronts=storefront,
                country=country, states=state, cities=city
            ).exists():
                raise ParseError("A shipping group already covers this city.")

For 5 storefronts, 10 states, and 100 cities, that's 5 × 10 × 100 = 5,000 individual .exists() queries. Just to validate the write hasn't even happened yet. And when the validation passes, the write itself used .add():

shipping_group.cities.add(*city_ids)

Under the hood, .add() first issues a SELECT to find which IDs don't already exist in the junction table, then issues a single INSERT for the remaining rows. Neither step is batched: the deduplication query grows to match the full ID set, and the single large INSERT can lock the table. For 5,000 cities, the SELECT + INSERT plus the 5,000 validation queries made the request timeout long before it finished.

The Solution

Three pieces: validate with in-memory set intersection instead of per-row queries, write directly to the .through table in batches, and offload past a threshold to a background task.

Step 1: Validate with set intersection, not per-row `.exists()`

Instead of checking each city against each existing group one query at a time, fetch all potentially conflicting groups in one query with a Prefetch that hoists the related IDs onto each instance. Then intersect locally:

from django.db.models import Prefetch

def validate_no_overlap(country, storefront_ids, state_ids, city_ids):
    # Fetch every group that might conflict, with all related IDs attached
    existing = ShippingGroup.objects.filter(
        country=country,
    ).prefetch_related(
        Prefetch(
            "storefronts",
            queryset=Storefront.objects.only("id"),
            to_attr="prefetched_storefronts",
        ),
        Prefetch(
            "states",
            queryset=State.objects.only("id"),
            to_attr="prefetched_states",
        ),
        Prefetch(
            "cities",
            queryset=City.objects.only("id"),
            to_attr="prefetched_cities",
        ),
    )

    request_storefronts = set(storefront_ids)
    request_states = set(state_ids)
    request_cities = set(city_ids)

    for group in existing:
        group_sfs = {sf.id for sf in group.prefetched_storefronts}
        group_sts = {st.id for st in group.prefetched_states}
        group_cts = {ct.id for ct in group.prefetched_cities}

        if (
            request_storefronts & group_sfs
            and request_states & group_sts
            and request_cities & group_cts
        ):
            raise ValidationError(
                f"A shipping group already covers this region."
            )

One query to fetch the groups, one query per Prefetch for the related IDs. Typically 3 to 5 queries total regardless of how many storefronts, states, or cities are being checked. The intersection runs entirely in Python, where a set membership check is O(1).

The to_attr on each Prefetch is the key detail: it hoists the filtered queryset onto each ShippingGroup instance as a plain list of objects (prefetched_storefronts, etc.), rather than leaving it as a lazily-evaluated queryset that would re-query on access. The set comprehensions then extract just the IDs for intersection.

Step 2: Write to the `.through` table directly

.add() looks like a bulk operation, but Django's Many-to-Many manager inserts rows one at a time. For a large set of IDs, the correct approach is to go directly to the auto-generated through model and use bulk_create:

through_model = ShippingGroup.cities.through
batch_size = 500

for i in range(0, len(city_ids), batch_size):
    chunk = city_ids[i : i + batch_size]

    # Verify these IDs actually exist in the database before inserting
    valid_ids = set(
        City.objects.filter(id__in=chunk, country=country_id)
        .values_list("id", flat=True)
    )

    objs = [
        through_model(shippinggroup_id=group_id, city_id=cid)
        for cid in valid_ids
    ]
    through_model.objects.bulk_create(objs, ignore_conflicts=True)

Three things happening here:

Batching in chunks of 500 keeps the transaction size bounded and prevents a single massive INSERT from locking the table for too long.
ignore_conflicts=True skips rows that already exist: no duplicate-key error, no need to pre-filter existing relations. If a city is already assigned to this group, the insert is silently ignored.
Pre-validating IDs against the database (City.objects.filter(id__in=chunk)) ensures you're not inserting garbage IDs that would fail a foreign key constraint. It's one query per batch, not one per row.

For 5,000 cities, that's 10 batches × 2 queries each = 20 queries instead of 5,000 inserts.

Step 3: Offload past a threshold to a background task

Even with batched bulk writes, processing 10,000+ rows synchronously will make the HTTP request hang. At some size, the operation belongs in a queue:

THRESHOLD = 500

def create_shipping_group(data):
    group = ShippingGroup.objects.create(name=data["name"], country=country)

    city_count = len(data["city_ids"])
    if city_count > THRESHOLD:
        assign_cities_to_group.delay(
            city_ids=data["city_ids"],
            country_id=country.id,
            group_id=group.id,
        )
    else:
        # Small enough — do it inline. At this count the SELECT + INSERT
        # in .add() is fast enough and keeps the code simpler.
        cities = City.objects.filter(id__in=data["city_ids"], country=country)
        group.cities.add(*cities.values_list("id", flat=True))

    return group

Below 500 cities: synchronous .add() is fine. Above 500: a Celery task takes over, the request returns immediately with the group created but cities still being assigned in the background. The task uses the same batched bulk_create path from Step 2.

Threshold choice matters: 500 was picked because it's well under a typical request timeout even with a slow database, but it's a number you should tune against your own infrastructure.

Why This Works

Validation is constant-time relative to the input size. The Prefetch queries are bounded by the number of existing groups in the country, not the number of cities being validated. Set intersection is O(n) in Python and negligible at typical group counts.

.through + bulk_create skips the deduplication penalty and avoids table locks. Under the hood, .add() runs a large SELECT to find which IDs are already in the table, then issues one giant INSERT for the rest — both unbounded operations. With ignore_conflicts=True, bulk_create skips the deduplication step entirely, and batching keeps the transactions small enough to avoid locking.

ignore_conflicts means idempotent writes. You can retry the Celery task without worrying about partial progress from a previous attempt. Rows that were already inserted in a prior batch are silently skipped on retry.

The threshold keeps the API responsive. Synchronous for small inputs (the common case), asynchronous for large ones without changing the interface. The caller always gets the same response shape. The group exists, cities are either assigned or being assigned.

Design Decision: The `.through` Model Changes What You're Responsible For

Using through_model.objects.bulk_create() instead of group.cities.add() means you're bypassing Django's Many-to-Many manager entirely. That's the point: the manager isn't designed for batch writes. But it also means you lose two things the manager normally gives you for free:

Signal dispatch. .add() fires m2m_changed signals that might be expected by other parts of the system (audit logs, cache invalidation). Writing to the through table directly does not. If those signals matter, you need to fire them manually or postpone logging to a post-write step.
Validation. The manager checks that the related object exists before inserting. Step 2 compensates with an explicit City.objects.filter(id__in=chunk) pre-check. If you skip that check and insert a non-existent ID, you get a ForeignKeyViolation in Postgres instead of a clean Django error.

Neither of these is a bad trade. Just a trade you should know you're making.

The Result

The validation step went from 5,000 queries — one per city-state-storefront combination — to about 5 regardless of input size. The write went from a single large INSERT with no batching to 10 batched chunks of 500 with idempotent conflict handling, or a background task for counts above the threshold.

The pattern (validate with set intersection, write to .through in batches, offload past a threshold) applies to any Django model with a large Many-to-Many field: tags, categories, user teams, regional assignments, or anywhere else you're adding hundreds or thousands of rows to a junction table.

How are you handling large Many-to-Many writes in your Django apps? Are you going through the through table directly, or have you found a different approach? Drop it in the comments.

¡Hasta luego!

It Worked on Every Environment Except Prod: Getting Daily Reports Right Across Timezones

Acel — Tue, 14 Jul 2026 06:00:00 +0000

Every day, a report runs: "what did each store sell yesterday?" One of the stores is in Lagos, the other in London. The report showed both stores as having zero sales for the last two hours of the day: wrong numbers, every day, in production. Here's the conversion pattern that fixed it.

The Problem

You store your timestamps in UTC. Django recommends it, Postgres defaults to it, and it keeps your data unambiguous. Order 582 was placed at 2025-03-10 23:15:00+00:00. Clean, portable, no ambiguity.

But a report that asks for "Tuesday's orders" needs to know what Tuesday means. Tuesday in Lagos starts at 11 PM Monday UTC. Tuesday in London starts at midnight UTC. If your reporting query uses UTC midnight for everyone, orders placed between 11 PM and midnight UTC get assigned to the wrong day for every store east of GMT.

The fix is deceptively simple: each store knows its timezone, and the reporting query converts the store's local day-bounds into a UTC range before filtering. But there's a landmine in the conversion, and it's one that only fires in production:

>>> import pytz, datetime
>>> store_tz = pytz.timezone("Africa/Lagos")
>>> start = datetime.datetime(2025, 3, 10, 0, 0, 0)
>>> store_tz.localize(start)
datetime.datetime(2025, 3, 10, 0, 0, tzinfo=<DstTzInfo 'Africa/Lagos' WAT+1:00:00 STD>)

That worked. But then the code runs again, maybe from a Celery retry, maybe from a helper that already called make_aware, and the datetime is already offset-aware:

>>> aware_start = store_tz.localize(start)     # fine
>>> store_tz.localize(aware_start)             # BOOM
ValueError: Not naive datetime (tzinfo is already set)

The same line fails because pytz.localize() refuses to touch an already-aware datetime. This didn't surface in development because the call path never produced an aware datetime in the dev environment, but in production, with re-queued tasks and retried jobs, it did.

The root cause isn't the localize() call itself: it's that an aware datetime reached the function at all. Guard the input before it hits datetime.combine(), and localize() never sees an aware value. The fix is one guard at the top of the function, and the lesson is that timezone-correct reporting needs both the right model and the right conversion hygiene.

Note on modern Django: The ValueError above is a pytz-specific quirk. Django 4.0 deprecated pytz in favour of Python's built-in zoneinfo, and Django 5.0 removed pytz support entirely. With zoneinfo you use datetime.replace(tzinfo=tz) instead of .localize(), which behaves differently. The code in this article uses pytz because the bug originated in a legacy codebase, and millions of Django apps are still in that position. But the underlying trap is the same regardless of library: passing an aware datetime that carries a UTC date into a function expecting to produce local midnight bounds will silently fetch the wrong day's data if you aren't guarding your inputs.

The Solution

Two pieces: a per-store timezone field, and a helper that safely turns a local calendar date into a UTC range for filtering.

Step 1: Give each store a timezone

# models.py
class Store(models.Model):
    name = models.CharField(max_length=255)
    timezone = models.CharField(
        max_length=50,
        default="Africa/Lagos",
        help_text="IANA timezone name, e.g. 'Africa/Lagos', 'Europe/London'.",
    )

One field. The Lagos store has "Africa/Lagos", the London store has "Europe/London". If a store never sets one, the default keeps it working (and wrong for anyone who notices, which is better than crashing).

Step 2: Convert local day-bounds to a UTC range

The reporting query needs a UTC start and end for the store's local day. A helper handles the conversion safely:

import pytz
from datetime import date, datetime, time, timedelta
from django.utils import timezone as dj_timezone

def local_day_bounds_utc(store_tz: str, target_date: date | datetime) -> tuple[datetime, datetime]:
    """Return (utc_start, utc_end) for the store's local calendar day."""
    tz = pytz.timezone(store_tz)

    # Normalize the date input — if an aware datetime arrives from a
    # Celery retry or pre-processed helper, extract the calendar date
    # in the store's own timezone.
    #
    # This matters because an aware datetime carries a UTC date component,
    # not a local one. A Lagos store at 11:30 PM local time is already the
    # next calendar day in UTC — passing that directly to datetime.combine()
    # would silently produce bounds for the wrong day.
    if isinstance(target_date, datetime) and not dj_timezone.is_naive(target_date):
        target_date = target_date.astimezone(tz).date()

    naive_start = datetime.combine(target_date, time.min)
    naive_end = datetime.combine(target_date + timedelta(days=1), time.min)

    aware_start = tz.localize(naive_start)
    aware_end = tz.localize(naive_end)

    return aware_start.astimezone(pytz.UTC), aware_end.astimezone(pytz.UTC)

naive_end is built as the start of the next day rather than time.max on the current day. This avoids microsecond edge cases on the upper boundary. The next day's midnight is unambiguous. For March 11 and a Lagos store, the UTC range becomes 2025-03-10 23:00+00:00 to 2025-03-11 23:00+00:00. That's Lagos-Tuesday in UTC.

Step 3: Filter with the UTC range

The reporting query now reads cleanly:

from django.db.models import Sum

store = Store.objects.get(id=store_id)
store_tz = pytz.timezone(store.timezone)
target_date = datetime.now(store_tz).date() - timedelta(days=1)  # yesterday, store-local

utc_start, utc_end = local_day_bounds_utc(store.timezone, target_date)

orders = Order.objects.filter(
    store=store,
    created_at__gte=utc_start,
    created_at__lt=utc_end,
)
totals = orders.aggregate(total=Sum("amount"))

One query, timezone-correct by construction. "Yesterday" is derived in the store's own timezone, not the server's. The function converts to UTC once, and the database does the rest.

Why This Works

The conversion is a pure function of data you already have. The store's timezone is a column on the store model. No API calls, no user-preference lookups, no frontend involvement. The reporting query just reads the field and does the math.

Postgres handles the UTC comparison natively. created_at is a timestamptz column, which stores everything as UTC internally. When Django passes two UTC-aware datetimes to __gte/__lt, Postgres can resolve the range with a plain index scan on the created_at column: no timezone arithmetic per row, no sequential scan. The conversion happens once per query, in Python. The database just compares two UTC values.

It works for any date, not just "yesterday." The helper takes a date, not a relative expression. Daily EOD reports, weekly summaries, arbitrary date-picker queries. All call the same function.

Design Decision: Put the Guard on the Input, Not the Output

The local_day_bounds_utc helper normalizes its input before doing anything else. datetime.combine() takes a date and a time. If you pass an aware datetime as the date argument, Python uses its date component, which is the UTC date, not the store-local date. A Lagos store at 11:30 PM local time on March 10 is already March 11 in UTC. Pass that aware datetime directly to combine and you silently get bounds for the wrong day, with no error raised.

In production, the input sometimes isn't a plain date. A Celery task retries and the retry wrapper has already called make_aware on the parameter. A helper upstream pre-processed the date into UTC. The isinstance + is_naive check at the top of the function catches this: if the incoming value is an aware datetime, it's converted to the store's own timezone first, and only the local calendar date is extracted. This means "yesterday" is always resolved in the store's timezone, regardless of what timezone the parameter arrived with.

The lesson: timezone correctness has two layers. The model (which timezone applies) and the conversion hygiene (is the input naive or aware, and does it carry the right date?). You need both. The second layer fails silently in every environment except the one where retries and re-queues happen.

The Result

The daily sales report now returns correct totals for every store, regardless of timezone. Adding a new store in a new city is one field change on the store record. The reporting query picks it up automatically. The input guard means the report produces correct results even when a date parameter arrives through an unexpected code path.

How are you handling per-store or per-tenant timezone-aware reporting? Are you doing it at the DB level, in Python, or have you found a third approach? I'd love to hear what's worked for you in the comments.

¡Hasta luego!

How to Prefetch Across GenericForeignKeys When You Can't Change the Schema

Acel — Mon, 06 Jul 2026 10:33:49 +0000

You don't always control the schema you work with. Sometimes you inherit a codebase where GenericForeignKey is threaded through the models, and a migration isn't on the table. Loading a page of 20 audit entries runs ~60 queries because Django's ORM can't prefetch across a GFK. Here's how to fix it without changing a single model.

The Problem

GenericForeignKey lets one table point at rows in multiple other tables without knowing which one at query time. The classic use case is an audit log, a notification feed, or a tagging system where the set of target types is open-ended.

But select_related and prefetch_related can't traverse a GFK. The ORM needs to know the target table ahead of time, and a content_type_id/object_id pair doesn't give it that until runtime. The result: every time you touch the GFK on an instance, you pay a query.

Take an activity log. One table, every row references some target: an order, a user, a product:

# models.py
from django.contrib.contenttypes.fields import GenericForeignKey, GenericRelation
from django.contrib.contenttypes.models import ContentType
from django.db import models

class ActivityLog(models.Model):
    actor = models.ForeignKey("User", on_delete=models.CASCADE)
    action = models.CharField(max_length=50)           # "created", "updated", "deleted"
    content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
    object_id = models.CharField(max_length=255)
    target = GenericForeignKey("content_type", "object_id")
    created_at = models.DateTimeField(auto_now_add=True)

class Order(models.Model):
    number = models.CharField(max_length=20)
    status = models.CharField(max_length=20)
    logs = GenericRelation(ActivityLog)

class Product(models.Model):
    name = models.CharField(max_length=255)
    sku = models.CharField(max_length=50)
    logs = GenericRelation(ActivityLog)

class User(models.Model):
    email = models.EmailField()
    logs = GenericRelation(ActivityLog)

This is a legitimate use of GFK. Audit logs should be polymorphic. But rendering a page of 20 activity feed entries, each showing the target's name and a link, hits the database once per entry to resolve log.target: 20 individual single-row lookups.

If the audit trail also needs actor details, or the target's related data, the count multiplies fast. Twenty entries can easily become 60-80 queries before pagination.

The Solution

Three steps. First, batch-resolve every GFK lookup in the page at once using compound queries. Second, attach the results to each instance as a cached private attribute. Third, let serializers read the cache with a live-query fallback, so the optimization is optional and the code never breaks if you forget to run it.

Step 1: Resolve the targets in bulk, not one by one

Collect the log entries you want to display, then group their object_id values by content type. Fire one query per target model, map the results back by ID, and attach the resolved instances:

from collections import defaultdict
from django.contrib.contenttypes.models import ContentType

def hydrate_activity_targets(entries):
    """Resolve all ActivityLog.target references in bulk."""
    if not entries:
        return

    # Collect all (content_type_id, object_id) pairs from the page
    refs_by_ct = defaultdict(set)
    for entry in entries:
        if entry.content_type_id and entry.object_id:
            refs_by_ct[entry.content_type_id].add(entry.object_id)

    # Resolve content types dynamically from the entries. One query,
    # no hardcoded model list — inherited codebases gain new types
    # and this adapts automatically.
    ct_by_id = {
        ct.id: ct
        for ct in ContentType.objects.filter(id__in=refs_by_ct.keys())
    }

    # One query per target model, map results back by (ct_id, str(id))
    target_map = {}
    for ct_id, obj_ids in refs_by_ct.items():
        ct = ct_by_id.get(ct_id)
        if ct is None:
            continue
        model = ct.model_class()
        if model is None:
            continue
        for obj in model.objects.filter(id__in=obj_ids):
            target_map[(ct_id, str(obj.id))] = obj

    # Attach to each entry
    for entry in entries:
        key = (entry.content_type_id, str(entry.object_id))
        entry._resolved_target = target_map.get(key)

This resolves every target reference on the page, regardless of type, with one query per content type. For a feed mixing 4 types, that's 4 queries instead of 20. The ContentType map is built from the entries themselves (no hardcoded model list), so the function automatically handles content types added after the hydration code was written.

Step 2: Handle the related data with compound queries

Resolving the target object is only the first layer. Audit entries also need the actor's name, or a display string that lives on a related model. You can extend the hydration to fetch those in bulk too. The pattern is the same: bucket by content type, compound Q filter across all buckets, map back by (content_type_id, object_id):

from django.db.models import Q

def hydrate_activity_details(entries):
    """Bulk-fetch display details for all resolved targets on the page."""
    if not entries:
        return

    # Build a model → ct_id map up front. Unlike Step 1, display formatting
    # is inherently type-specific — a product shows name and SKU, a user
    # shows their full name — so hardcoding known types here is correct.
    ct_map = ContentType.objects.get_for_models(Product, User, Order)
    ct_id_by_model = {model: ct.id for model, ct in ct_map.items()}

    # Group entries by content type
    obj_ids_by_ct = defaultdict(list)
    entry_by_target_id = defaultdict(list)  # target.id → [entries with that target]
    for entry in entries:
        target = getattr(entry, "_resolved_target", None)
        if target is None:
            continue
        ct_id = ct_id_by_model.get(type(target))
        if ct_id is not None:
            obj_ids_by_ct[ct_id].append(target.id)
            entry_by_target_id[(ct_id, target.id)].append(entry)

    # Fetch products in one query
    product_ct = ct_id_by_model.get(Product)
    if product_ct in obj_ids_by_ct:
        product_display = {
            p.id: f"{p.name} ({p.sku})"
            for p in Product.objects.filter(
                id__in=obj_ids_by_ct[product_ct]
            )
        }
        for product_id, display in product_display.items():
            for entry in entry_by_target_id[(product_ct, product_id)]:
                entry._target_display = display

    # Fetch users with their profile in one query
    user_ct = ct_id_by_model.get(User)
    if user_ct in obj_ids_by_ct:
        user_display = {
            u.id: u.get_full_name()
            for u in User.objects.filter(
                id__in=obj_ids_by_ct[user_ct]
            ).select_related("profile")
        }
        for user_id, display in user_display.items():
            for entry in entry_by_target_id[(user_ct, user_id)]:
                entry._target_display = display

    # Repeat the same pattern for Order or any other content type.
    # Targets that don't match a handled type fall back gracefully through
    # the serializer's str(target) path.

Building the display map in a dict comprehension first keeps each pass over entries to O(n). One iteration per content type, not a nested loop over every object × entry combination. For 200 entries and 50 products, that's 50 + 200 checks instead of 50 × 200.

Step 3: Serializers that read the cache with a fallback

Serializers read the cached attributes when they're present, and fall back to a live query when they aren't, so the serializer works whether or not the hydration ran:

class ActivityLogSerializer(serializers.Serializer):
    target_name = serializers.SerializerMethodField()
    target_type = serializers.SerializerMethodField()

    def get_target_name(self, entry):
        display = getattr(entry, "_target_display", None)
        if display is not None:
            return display
        # Cache wasn't populated — fall back to a live GFK lookup.
        target = entry.target
        return str(target) if target else None

    def get_target_type(self, entry):
        target = getattr(entry, "_resolved_target", entry.target)
        if target is None:
            return None
        return type(target).__name__

The getattr(entry, "_target_display", None) pattern is the decoupling mechanism. If hydration ran, the attribute is present and entry.target never fires. If it didn't run, the serializer falls back to a live GFK query and everything still works. The hydration logic is an optional optimization — the serializer doesn't care whether it was called.

Why This Works

One query per content type, not per row. The id__in filter resolves all targets of a given type in a single query regardless of how many entries reference that type. A feed with 20 entries across 4 types goes from 20+ queries to 4.

The private-attribute convention is lazy and safe. _resolved_target and _target_display are set when hydration runs and silently absent when it doesn't. The getattr(..., fallback) pattern means no code path breaks. The serializer degrades to live queries without any conditional branching.

No schema change required. This pattern doesn't touch the models, doesn't need a migration, and doesn't alter how GFK works. It's a presentation-layer optimization. You can introduce it incrementally to the slowest pages and leave the rest untouched.

It composes with existing select_related/prefetch_related. If your queryset already uses ORM-level prefetch for non-GFK relationships (like select_related("actor")), the hydration runs after that, filling in only the gaps the ORM can't reach.

Design Decision: The Fallback Is Silent, and That's Both a Feature and a Risk

Because getattr(entry, "_resolved_target", entry.target) swallows a missing attribute silently, a typo in the attribute name (_resolvedTarget) will never raise an error. It'll just quietly bypass the cache and fire a live query on every call. The page still renders correctly, but your query count silently regresses.

Mitigations: keep the _ prefix convention consistent, test the query count in integration tests (not just correctness), and consider a debug-mode assertion that logs a warning when hydration is expected but the cache attribute is absent.

One more operational note: if the set of target types is large, the id__in per-content-type approach fires many small queries rather than one big one. At dozens of content types, a single query that fetches all targets of any type via UNION may be faster — but for the typical audit log with half a dozen entity types, the per-type approach is simpler and easier to debug.

The Result

An activity feed that used to cost ~60 queries for 20 entries — the initial queryset (1), a per-entry GFK target lookup (20), an actor display-name lookup per entry (20), and a related-field fetch per target (20+, e.g. user profiles, product details) — now costs about 6: one per target content type plus the initial fetch.

The two hydration functions compose between the queryset and the serializer:

entries = ActivityLog.objects.select_related("actor").order_by("-created_at")[:20]
hydrate_activity_targets(entries)
hydrate_activity_details(entries)
return ActivityLogSerializer(entries, many=True).data

No schema change, no migration, no ORM tricks. The hydration functions are drop-ins that run between the queryset and the serializer, and if you forget to call them, nothing breaks. The serializers fall back to live queries.

How are you handling N+1 across GenericForeignKeys in your apps? Are you hand-rolling prefetches, or have you found a different pattern? Drop your approach in the comments.

¡Hasta luego!

How I Moved Real-Time Out of Django (and Made Everything Simpler)

Acel — Tue, 30 Jun 2026 08:44:58 +0000

Your users want live updates: an order flips to paid, a notification pops, a dashboard number ticks up without a refresh. The obvious answer in Django is Channels. I reached for it first too. But as our scale grew, the costs of keeping connections in-process pushed me to rethink the architecture. I let Django stop handling WebSockets entirely, and almost everything got simpler. Here's the pattern that replaced it.

The Problem

Django is a request/response framework. It processes a request, returns a response, and moves on. Real-time notifications — a dashboard ticking up, an order status flipping live — need a server that holds a connection open for every connected client. That is a fundamentally different job.

The standard answer in the Django ecosystem is Channels. It moves you to ASGI, gives you consumers, and works well, especially when your real-time needs are deep and bidirectional.

Ours weren't. We needed server→client push: notify a user when an order completed, or when a payment landed. The connections were mostly idle. Channels gave us that, but it came with costs that started hurting at scale.

The concrete problem was this: every open WebSocket connection consumed memory and a small slice of CPU time on our app servers. A thousand connected dashboards was fine. Ten thousand, across dozens of tenants, each holding a persistent socket. Suddenly, our workers were doing two very different jobs at once. Serving fast API responses and babysitting long-lived, mostly-quiet connections. Both suffered.

What made it brittle was the reconnect storm. Deploy a new build, restart a server, or hit a brief network partition, and every connected client disconnects and immediately reconnects. All at once. That thundering herd of TLS handshakes, authentication, and subscription requests would spike CPU to 100% on every app server as it tried to spin up thousands of ASGI consumer instances simultaneously, occasionally knocking them over entirely before the retry backoff kicked in.

There's also the smaller but telling friction of auth. Authenticating the WebSocket handshake means reaching your existing auth (DRF/JWT) from inside an ASGI scope. I ended up writing middleware that reconstructed a DRF Request out of the raw scope just to reuse the auth I already had. It worked, but it was a sign: I was bending the framework to do something it wasn't built for.

The turning point was asking: why is my web framework in the business of holding connections at all?

For a fire-and-forget server→client push, it shouldn't be. There are servers built specifically to hold millions of open connections and do nothing else. The only two things your backend needs to do are say who's allowed to listen, and publish events.

The Solution

Put a dedicated pub/sub gateway in front of your app. I used Centrifugo, a standalone real-time server. Clients connect to it, not to Django. Django goes back to being a plain, boring WSGI/sync app and plays two small roles:

Issue a short-lived connection token that embeds which channels this user may subscribe to.
Publish events to the gateway over its HTTP API.

The gateway holds the connections. Django holds nothing.

Step 1: Issue a token that carries its own permissions

When a client wants to connect, it asks your backend (over a normal authenticated request) for a connection token. The token is a JWT whose claims list the exact channels the user may subscribe to. The gateway verifies the signature and authorizes subscriptions without a single database lookup:

# realtime/auth.py
import time
import jwt
from django.conf import settings


class RealtimeTokenService:
    """Issues short-lived JWTs for connecting to the realtime gateway."""

    def generate_connection_token(self, user) -> str:
        tenant_id = user.tenant_id

        # Channel grants are baked into the token, so the gateway authorizes
        # subscriptions with zero database lookups on connect.
        channels = [
            f"user_{user.id}",
            f"critical:user_{user.id}",
            f"tenant_{tenant_id}",
            f"critical:tenant_{tenant_id}",
        ]

        claims = {
            "sub": str(user.id),
            "exp": int(time.time()) + settings.REALTIME_TOKEN_TTL_SECONDS,
            "info": {"name": user.get_full_name(), "email": user.email},
            "channels": channels,
        }
        return jwt.encode(claims, settings.REALTIME_HMAC_SECRET, algorithm="HS256")

This is the key idea: token-as-permission. The channel names encode your authorization model. A user gets their own user_{id} channel and their tenant's tenant_{id} channel, and nothing else. Multi-tenant isolation falls out of the channel naming: a user simply has no grant for another tenant's channel, so the gateway will refuse the subscription.

Step 2: Hand the token out behind your normal auth

The endpoint that mints the token is an ordinary authenticated view. Your existing auth stack protects it; no ASGI gymnastics:

# realtime/views.py
class RealtimeTokenView(APIView):
    permission_classes = [IsAuthenticated]

    def post(self, request):
        token = RealtimeTokenService().generate_connection_token(request.user)
        return Response(
            {"token": token, "socket_url": settings.REALTIME_SOCKET_URL}
        )

The client takes {token, socket_url}, opens a WebSocket to the gateway, and subscribes to its channels. Django is now out of the connection entirely.

Step 3: Publish events over HTTP

To push an update, your backend POSTs to the gateway's publish API. No connection state, no sockets: just an HTTP call:

# realtime/publisher.py
import requests
from django.conf import settings


def push_event(channel, event_type, payload, *, recoverable=False, timeout=10.0):
    # The "critical:" namespace is configured on the gateway with message
    # history + recovery, so clients can catch up after a reconnect.
    final_channel = f"critical:{channel}" if recoverable else channel

    resp = requests.post(
        f"{settings.REALTIME_API_URL}/publish",
        json={
            "channel": final_channel,
            "data": {"type": event_type, "payload": payload},
        },
        headers={"X-API-Key": settings.REALTIME_API_KEY},
        timeout=timeout,
    )
    resp.raise_for_status()

Notice the critical: channel prefix. On the gateway, that namespace is configured to keep a short history so a client that briefly drops can recover missed messages on reconnect:

{
  "namespaces": [
    { "name": "critical", "history_size": 50, "history_ttl": "120s", "force_recovery": true }
  ]
}

Ephemeral events (a "user is typing" blip) publish to the bare channel; events you can't afford to lose (a completed order) publish to critical: and survive a reconnect.

Step 4: Make publishing reliable, and don't block the request

Publishing is a network call to a separate service. You do not want it on the request's critical path, and you want it to survive a transient blip. Wrap it in a Celery task with retries and backoff:

# realtime/tasks.py
import logging
from requests.exceptions import RequestException, HTTPError
from celery import shared_task
from .publisher import push_event

logger = logging.getLogger(__name__)


@shared_task(bind=True, max_retries=3, default_retry_delay=5, retry_backoff=True)
def publish_realtime_event(self, channel, event_type, payload, recoverable=False):
    try:
        push_event(channel, event_type, payload, recoverable=recoverable)
    except HTTPError as exc:
        # A 4xx error (bad API key, malformed payload) is a deterministic
        # failure that retries can't fix. Log it and drop it.
        # A 5xx error might be transient, so retry it.
        if 400 <= exc.response.status_code < 500:
            logger.error("Deterministic 4xx error on %s, dropping.", channel)
            return
        raise self.retry(exc=exc)
    except RequestException as exc:
        # Pure network timeouts or connection errors — retry with backoff.
        raise self.retry(exc=exc)
    except Exception:
        # A serialization bug won't fix itself on a retry. Log and drop it,
        # rather than burning three attempts on a guaranteed failure.
        # By not re-raising, Celery marks the task as successful and removes
        # it from the queue — no poison pill looping forever.
        logger.exception("Dropping unrecoverable realtime event on %s", channel)

That except split matters: retry the transient, drop the deterministic. A flaky network deserves another try; a payload that can't be JSON-encoded will fail identically three times in a row, so retrying it is just noise.

Firing an event from anywhere in your app is now a one-liner:

publish_realtime_event.delay(
    channel=f"tenant_{order.tenant_id}",
    event_type="order.completed",
    payload={"order_id": order.id, "total": str(order.total)},
    recoverable=True,
)

Why This Works

Your web tier goes back to being stateless. Django stays on WSGI. No ASGI migration, no async server, no sockets held in your workers. You can scale, restart, and deploy the web tier like any other stateless service. The open connections live on the gateway and aren't disturbed.

Connections scale independently. Holding a lot of idle connections is a specialized job. A purpose-built gateway does it on its own box, tuned for that, while your app servers stay sized for request throughput.

Auth has zero connect-time cost. Because the token carries its channel grants, the gateway never calls back into your database to authorize a subscription. Ten thousand clients reconnecting after a blip is ten thousand signature checks, not ten thousand DB queries.

Multi-tenancy is just naming. Tenant isolation isn't a separate access-control layer. It's the channel names in the token. There's no code path by which a user can subscribe to a channel they weren't granted.

Delivery is fire-and-forget but durable. Publishing happens off the request path via Celery, retries on transient failure, and the critical: namespace lets clients recover what they missed across a reconnect.

Design Decision: The Token Is a Cache, So It Can Go Stale

Baking permissions into the token is what buys you DB-free connects. But a token is a snapshot. If a user's access changes (you remove them from a tenant, say) and their token still has 24 hours to live, the gateway will keep honoring the old grants until it expires. You've traded revocation freshness for connect-time performance.

That's usually the right trade for a notification stream, but be deliberate about it:

Keep the TTL short and have the client transparently re-fetch a token. Shorter tokens = smaller stale window.
For true revocation, the gateway can be told to force-disconnect a user or refuse channels server-side. Reach for that only when a stream is sensitive enough to need it.

One more operational gotcha: a single gateway is tempting to share across environments, but tenant_42 in staging and tenant_42 in production are the same channel name: cross-talk waiting to happen. If you must share one broker, prefix channels with the environment (prod_tenant_42, staging_tenant_42) so the namespaces can't collide.

And to be honest about the path here: I shipped the Channels version first. It worked. But the friction of running an async server and bridging my existing auth into the ASGI scope is exactly what made the gateway approach worth it. If your real-time needs are deep and bidirectional (collaborative editing, presence), in-process Channels may genuinely fit better. For "push updates to subscribed clients," letting something else hold the sockets is the simpler system.

The Result

Adding a live update anywhere in the app is now one .delay() call. The web tier never learned what a WebSocket is. Connections, fan-out, history, and recovery are the gateway's problem; authorization is a signed list of channel names; delivery is a retrying background task. Django went back to doing the thing it's good at. And the real-time problem moved to a server built for it.

How are you doing real-time in your Django apps — in-process with Channels, or have you pushed connections out to a gateway? I'd love to hear what's worked for you in the comments.

¡Hasta luego!

How I Built a "Set It and Forget It" Sync System with Django Signals

Acel — Tue, 16 Jun 2026 06:00:00 +0000

Change a product's price anywhere in your app, and it instantly syncs to a third-party marketplace. No manual triggers, no polling, no fragile save() overrides. Here's the signal pattern that powers it.

The Problem

In our app, a product's name or price can change from eight different places. The edit page. Bulk import. The variant editor. A pricing rule engine. An API endpoint that processes webhooks from suppliers. Every few weeks, someone adds a new feature and creates yet another code path that mutates a product.

We needed every one of those changes, no matter where they came from, to sync to an external marketplace. The naive approach would be to add a sync call to each code path. That's eight places to maintain (and counting), eight chances to forget, and eight places that break if the sync API changes.

Django's post_save signals solve the discovery problem: hook into a model's save event and you catch every change, from every code path, in one place. Signals get a bad rap — fairly, they make control flow hard to trace. But when you need to react to changes from everywhere without touching anywhere, this specific discovery problem is exactly what they were designed for.

There's a catch, though. If ten prices change in a single request, say, a bulk import, a naive signal handler fires ten times. That's ten API calls in rapid succession. At best, you are wasting resources. At worst, the external API rate-limits you.

We needed signals to detect changes, but we needed to batch them.

The Solution

Here's the three-part pattern:

A signal handler that collects change references instead of acting on them immediately.
A per-thread set that deduplicates for free — adding the same product twice does nothing.
A flush callback deferred to transaction.on_commit that processes everything once the database transaction lands.

Step 1: Register the signal

In your app's apps.py, connect post_save to the model that holds pricing:

# shopping/apps.py
from django.apps import AppConfig

class ShoppingAppConfig(AppConfig):
    name = "shopping"

    def ready(self):
        from django.db.models.signals import post_save
        from shopping.models import PriceRecord
        from shopping.signals import on_price_change

        post_save.connect(
            on_price_change,
            sender=PriceRecord,
            dispatch_uid="shopping_price_change",
        )

dispatch_uid prevents duplicate connections if ready() runs twice, a common gotcha during development with auto-reload.

Step 2: Collect, don't act

The signal handler doesn't call an API. It just adds a reference to a set and registers a flush callback:

# shopping/signals.py
import threading
from django.db import transaction

_local = threading.local()


def _get_pending():
    if not hasattr(_local, "pending"):
        _local.pending = set()
    return _local.pending


def on_price_change(sender, instance, **kwargs):
    # Record just enough to look up the product later
    _get_pending().add(instance.object_id)
    transaction.on_commit(flush_changes)

That's it. Four lines of logic. The handler doesn't care how many prices changed or where the change came from. It just records what changed and defers action to the flush.

Notice that we use threading.local() instead of a standard module-level variable. This ensures that each thread gets its own isolated storage.

Why transaction.on_commit? If the transaction rolls back, the price change never happened, so the flush callback is discarded. You never sync data that wasn't committed.

Step 3: Flush once per transaction

When the transaction lands, the flush handler fires. It snapshots the set, clears it immediately, and processes everything in one batch:

def flush_changes():
    pending = _get_pending()
    refs = pending.copy()
    pending.clear()

    if not refs:
        return

    from shopping.services import SyncService
    SyncService.handle_price_changes(refs)

The key detail: we copy the set before clearing it. If clearing happened after processing, and processing raised an exception, stale refs would linger into future transactions. Snapshot-first is defensive.

This clear() is also what keeps requests perfectly isolated. Once a transaction commits and the flush runs, the set is empty and ready for the next request.

Step 4: Resolve and dispatch

The service layer resolves the raw references into business entities, groups them by destination, and dispatches one task per group. The grouping is the important part. One API call per store, regardless of how many products changed:

# shopping/services.py
from collections import defaultdict

class SyncService:

    @classmethod
    def _resolve_to_products(cls, refs: set[int]):
        """
        Resolve product ID references to actual Product instances
        with their Store relationship.  Fetches everything in ONE
        query using filter(id__in=...), silently ignoring stale
        IDs that no longer exist.
        """
        products = Product.objects.filter(
            id__in=refs
        ).select_related("store")

        resolved = []
        for product in products:
            resolved.append((product, product.store_id))
        return resolved

    @classmethod
    def handle_price_changes(cls, refs: set[int]):
        resolved = cls._resolve_to_products(refs)

        # Group changes by the store they belong to
        by_store = defaultdict(list)
        for product, store_id in resolved:
            by_store[store_id].append(product)

        # One API call per store, regardless of how many products changed
        for store_id, products in by_store.items():
            sync_to_marketplace.delay(store_id=store_id, products=products)

The sync_to_marketplace task is a Celery task that calls the external API. It's configured with retries and backoff for transient failures:

@shared_task(bind=True, max_retries=3, default_retry_delay=60)
def sync_to_marketplace(self, store_id, products):
    try:
        provider.bulk_update(store_id, products)
    except Exception as exc:
        raise self.retry(exc=exc)

Why This Works

Deduplication is free. A set naturally deduplicates, adding the same object_id twice is a no-op. If a price changes twice in the same request (say, a pricing rule recalculates it), the flush handler sees it once. And when it fires, it reads the latest price from the database. The most recent value always wins.

Transaction safety is built-in. transaction.on_commit guarantees the flush only runs after the database confirms the change. If the transaction rolls back (a validation error, a constraint violation, a raise somewhere), the callback is discarded. You never sync phantom data.

Batch resolution avoids N+1. The service resolves all references in bulk queries, not one at a time. For 50 changed products, it takes exactly 1 query regardless of count. No per-product lazy loading.

Design Decision: Avoiding the Global State Pitfall

You might be wondering why we used threading.local() in Step 2 instead of a simple module-level variable like _pending_changes = set().

A basic module-level set shares state across every request handled by the same worker process. If User A's request rolls back, stale refs from their failed transaction sit in the global set. When User B's request commits ten minutes later on the same worker, the flush accidentally picks up both User A's and User B's products.

By using threading.local(), we protect against this cross-request leakage. Even if a transaction rolls back, any leftover references in that thread's set will simply be cleared on its next successful commit. And in the rare event a stale reference makes it to the resolver, it evaluates to nothing and is skipped silently.

One thing to watch for: use .filter() when looking up products in your resolver, not .get(). .filter() returns an empty queryset gracefully. .get() throws DoesNotExist and tanks your flush.

The Result

The user experience is deceptively simple. A user toggles "Sync product prices" on a store configuration page. From that moment on, any price change from any code path in the application syncs to the external marketplace within seconds.

No one has to remember to add a sync call to new features. No one has to track down every place a price can change. No one monitors a queue for failures (Celery retries handle that). The system just works.

How are you handling external API syncs in your Django apps? Are you using signals, or do you prefer a different pattern? Drop your approach in the comments.

¡Hasta luego!

How to Get Free SSL Certificates with Docker & LetsEncrypt

Acel — Tue, 23 Jul 2024 20:44:05 +0000

"An SSL certificate is a digital certificate that authenticates a website's identity and enables an encrypted connection. SSL stands for Secure Sockets Layer, a security protocol that creates an encrypted link between a web server and a web browser." - kaspersky

Majority of websites built today use SSL certificates, and if you are building a website in 2024, you will need to learn how to get one too!

There are several approaches to getting an SSL certificate for your domain. But in this article, we will take a look at generating SSL certificates with Let's Encrypt - a nonprofit certificate authority (CA) that provides free SSL/TLS certificates for enabling HTTPS (secure HTTP) on websites. In addition to this, automating the renewal process with Certbot and using a Docker image that was built on top of the official Nginx Docker images.

Prerequisites

To successfully complete this guide, you should be familiar with the following:

Docker and Docker Compose
Virtual machines from cloud providers, e.g. Azure VMs, AWS EC2 etc.
Linux

It is a good idea to containerize your app with Docker, but if you don't want to, you can still follow along just fine!

Configuring Certbot and Nginx

In the root directory of your project, please create a docker-compose file.

touch docker-compose.yml

Then paste the following code in the docker-compose.yml file.

version: '3'

services:
  nginx:
    image: jonasal/nginx-certbot:latest
    restart: unless-stopped
    environment:
      - CERTBOT_EMAIL
    env_file:
      - ./nginx-certbot.env
    ports:
      - 80:80
      - 443:443
    volumes:
      - nginx_secrets:/etc/letsencrypt
      - ./user_conf.d:/etc/nginx/user_conf.d

volumes:
  nginx_secrets:

The code we just pasted above is a YAML configuration for our Nginx docker image. It makes use of the jonasal/nginx-certbot:latest image that has certbot built on top of Nginx.

Now, let us create a nginx-certbot.env file to store the variables needed for our Nginx image.

touch nginx-certbot.env

Then paste this into your nginx-certbot.env file

# Required
CERTBOT_EMAIL=your@email.com

# Optional (Defaults)
DHPARAM_SIZE=2048
RSA_KEY_SIZE=2048
ELLIPTIC_CURVE=secp256r1
RENEWAL_INTERVAL=8d
USE_ECDSA=1
STAGING=1

Next, we create a server configuration file to configure our Nginx server.

touch server.conf

server {
    # Listen to port 443 on both IPv4 and IPv6.
    listen 443 ssl default_server reuseport;
    listen [::]:443 ssl default_server reuseport;

    # Domain names this server should respond to.
    server_name yourdomain.com www.yourdomain.com;

    # Load the certificate files.
    ssl_certificate         /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key     /etc/letsencrypt/live/yourdomain.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/yourdomain.com/chain.pem;

    # Load the Diffie-Hellman parameter.
    ssl_dhparam /etc/letsencrypt/dhparams/dhparam.pem;

    # Redirect non-https traffic to https
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }

    return 200 'Let\'s Encrypt certificate successfully installed!';
    add_header Content-Type text/plain;
}

Now, all we need to do is build the docker image and run it on our server.

docker compose -f docker-compose.yml build

Next, move the images to the server whose IP address is mapped to a domain name you own and run this command:

docker compose -f docker-compose.yml up

The command starts the server and Certbot automatically creates new SSL certificates for us. Try navigating to the domain name mapped to the server, you should see a "not trusted" page.

This is because we used "test" certificates to make sure that our configuration works fine. Issuing of live certificates is rate limited, so using test/staging certificates first is a better approach to ensure that it runs fine.

Now, we will update our nginx-certbot.env file to enable us generate live SSL certificates. Change the staging value from 1 to 0.

...
STAGING=0

Stop the server with ctrl+c and run the command below to regenerate SSL certificates.

docker exec -it <container_name> /scripts/run_certbot.sh force

Start up the server again

docker compose -f docker-compose.yml up

Now, navigate to your domain name. Your site should open up just fine!

Certbot and Nginx configurations for Dockerized apps

Assuming you dockerized your app, you will need to make a few more changes to what we have done so far.
First, we update the docker-compose.yml file so that the Nginx service depends on your app.

    ...
    volumes:
      - nginx_secrets:/etc/letsencrypt
      - ./user_conf.d:/etc/nginx/user_conf.d
    depends_on:
      - web

  web:
    container_name: core_app
    build: .
    restart: always
    ...

volumes:
  nginx_secrets:

Where web is the name of your app service.

Then, we update the server.conf file to point to our web server.

upstream webapp {
    server core_app:8000;
    # core_app is the container name of the web server
    # 8000 is the port for the web container
}
server {
    # Listen to port 443 on both IPv4 and IPv6.
    listen 443 ssl default_server reuseport;
    listen [::]:443 ssl default_server reuseport;

    # Domain names this server should respond to.
    server_name yourdomain.com www.yourdomain.com;

    server_tokens off;
    client_max_body_size 20M;

    # Load the certificate files.
    ssl_certificate         /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key     /etc/letsencrypt/live/yourdomain.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/yourdomain.com/chain.pem;

    # Load the Diffie-Hellman parameter.
    ssl_dhparam /etc/letsencrypt/dhparams/dhparam.pem;

    # Redirect non-https traffic to https
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }

    location / {
        proxy_pass http://webapp;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_redirect off;
    }
}

Now, Nginx should be routing traffic directly to your web server (docker container).

Conclusion

We have successfully created free SSL certificates for our domain name that renew automatically, so we never have to worry about it unless our server goes down.

In addition to this article, you can learn more about this approach here: https://github.com/JonasAlfredsson/docker-nginx-certbot/tree/master

Thanks for reading.

¡Hasta luego!

DEV Community: Acel

From O(N ) to O(1): Scaling M2M Validation in Django

The Problem

The Solution

Step 1: Validate with set intersection, not per-row .exists()

Step 2: Write to the .through table directly

Step 3: Offload past a threshold to a background task

Why This Works

Design Decision: The .through Model Changes What You're Responsible For

The Result

It Worked on Every Environment Except Prod: Getting Daily Reports Right Across Timezones

The Problem

The Solution

Step 1: Give each store a timezone

Step 2: Convert local day-bounds to a UTC range

Step 3: Filter with the UTC range

Why This Works

Design Decision: Put the Guard on the Input, Not the Output

The Result

How to Prefetch Across GenericForeignKeys When You Can't Change the Schema

The Problem

The Solution

Step 1: Resolve the targets in bulk, not one by one

Step 2: Handle the related data with compound queries

Step 3: Serializers that read the cache with a fallback

Why This Works

Design Decision: The Fallback Is Silent, and That's Both a Feature and a Risk

The Result

How I Moved Real-Time Out of Django (and Made Everything Simpler)

The Problem

The Solution

Step 1: Issue a token that carries its own permissions

Step 2: Hand the token out behind your normal auth

Step 3: Publish events over HTTP

Step 4: Make publishing reliable, and don't block the request

Why This Works

Design Decision: The Token Is a Cache, So It Can Go Stale

The Result

How I Built a "Set It and Forget It" Sync System with Django Signals

The Problem

The Solution

Step 1: Register the signal

Step 2: Collect, don't act

Step 3: Flush once per transaction

Step 4: Resolve and dispatch

Why This Works

Design Decision: Avoiding the Global State Pitfall

The Result

How to Get Free SSL Certificates with Docker & LetsEncrypt

Prerequisites

Configuring Certbot and Nginx

Certbot and Nginx configurations for Dockerized apps

Conclusion

Step 1: Validate with set intersection, not per-row `.exists()`

Step 2: Write to the `.through` table directly

Design Decision: The `.through` Model Changes What You're Responsible For