Deleting a link doesn't invalidate its cache entry

Nobody has started this yet — be first.

Business impact

A user deletes a link expecting it to stop working immediately -- that's the entire point of a delete button. If the link had recently received any traffic (exactly the case where deleting it matters most -- a compromised/wrong/embarrassing link that's actively being clicked), Redis keeps serving the old redirect for up to a full hour (DEFAULT_CACHE_TTL_SECONDS) after the "successful" 204 No Content delete response. This is the specific failure mode a cache-aside layer is supposed to prevent by design, and it is now silently broken: a takedown request (legal, security, abuse) can appear to succeed while the link keeps redirecting.

Problem

delete_url sets short_url.is_active = False, commits, and returns "", 204 -- it never calls invalidate_cache(slug).

Current behavior

Compare this to resolve_short_url, which correctly calls invalidate_cache(slug) when it discovers an expired entry on a cache hit -- the same helper already exists and is already imported in this file, it is just not called from delete_url.

Expected behavior

Immediately after DELETE /api/urls/<slug> returns 204, the next GET /<slug> returns 404, regardless of whether the slug had a warm cache entry.

Steps to reproduce

Create a short URL, e.g. slug "abc".
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:5000/abc # 302, warms the cache
curl -X DELETE http://localhost:5000/api/urls/abc # 204
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:5000/abc # still 302 -- should be 404

Why this matters

This is precisely the invalidation rule this project's caching layer is built around ("deleting or updating a ShortURL must invalidate its Redis entry in the same request") -- see the cache-aside section of the project's README. A cache-aside pattern is only as correct as its invalidation paths; forgetting one write path (delete) while getting the others right (expiry-on-hit) is the most common way these systems end up serving stale data in production.

Suggested approach

Look at how resolve_short_url calls invalidate_cache(slug) when it detects a stale/expired cache entry, and add the equivalent call to delete_url at the point where the row is deactivated.

Acceptance criteria

DELETE /api/urls/<slug> invalidates the Redis cache entry in the same request, before returning 204
A subsequent GET /<slug> returns 404 immediately, even if the slug had a warm cache entry from before the delete
Deleting an unknown slug still returns 404 (unchanged)

Verification

pytest practice_tickets/tests/test_ticket_08_delete_cache_invalidation.py -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b fix/delete-cache-invalidation

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/delete-cache-invalidation

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

URL Shortener with Click Analytics

A production-shaped Flask URL shortener: app-factory pattern, Blueprints, Flask-SQLAlchemy, and a real Redis cache-aside layer in front of Postgres, with per-link click analytics.

Fork on GitHub

Download

Setup

URL Shortener with Click Analytics

git clone <your-fork>
cd FlaskDevTraining/url_shortener_analytics
cp .env.example .env
docker compose up --build   # Postgres + Redis + the Flask app (dev server, debug + reload on)

Migrations run automatically on container startup (see ). Once it is up: