DEV Community: MaxLJ

Building Hierarchical Destination URLs Without Killing Your Database

MaxLJ — Thu, 04 Jun 2026 14:25:32 +0000

One of the more challenging engineering problems we encountered while building our travel portal, was figuring out a decent URL structure for destination hubs.
On the face of it, this one looks relatively easy to crack. You've got a geographically based hierarchy: Global Region, Subregion, Country, Local Region, Local Subregion & City - & it would be nice to have URLs that make sense with that structure. Something that's clean, readable, semantically meaningful, and also SEO-friendly sounds pretty great. The problem is, turning that into a system that doesn't grind your application to a halt.

/destinations/{global-region}/{global-subregion}/{country}/{local-region}/{local-subregion}/{city}/

The problem we're talking about isn't tied to any particular framework. Whether you're working with Django, FastAPI, Flask, Rails, Laravel, or something you cobbled together yourself, if your content has a recursive tree structure & your URLs need to mirror that tree, you'll run into the same roadblock.

The Naive Approach and Exactly Why It Falls Flat

The super obvious path to take is recursive parent traversal whenever you need it. Each node in your hierarchy has a parent node it can latch onto . To build a full URL for any old node, you just have to walk up the tree:

def get_full_path(node, db):
    parts = []
    current = node
    while current is not None:
        parts.append(current.slug)
        current = db.fetch_by_id(current.parent_id)  # one DB query per level
    parts.reverse()
    return "/" + "/".join(parts) + "/"

This works great in development when you only have 20 nodes to worry about. But in production with 400+ nodes and actual traffic coming in, it's basically executing one database query per page render - one for every level in the hierarchy. So a six-level deep spot like Uvero Alto just unleashes six sequential round-trips to the database before you've even started throwing page content on the screen. And then - to make matters worse - multiply that by all the concurrent users trying to get in on the action and connection pool exhaustion becomes a real possibility pretty darn quick.

The second thing that usually pops into people's heads is eager loading - grab the node and all its ancestors in a single swoop with a JOIN. That works just fine if your ORM has got the ability to handle recursive CTEs or if you somehow manage to figure out the max depth ahead of time. But most do not handle arbitrary-depth recursive relationships with any kind of finesse. And, a lot of the time, you just can't predict the depth in advance.

The Solution: Pre-Computing at Write Time

The core idea here is that the URL for a destination node only changes when the node or one of its parents is updated - so you don't need to recalculate it every time you go to read it. Just do the calculation once, stash the result, and then just read it straight out.

When you decide to keep a node, take a moment to calculate and store three related pieces of info:

def compute_node_metadata(node, fetch_parent_fn):
    """
    fetch_parent_fn: callable that takes a parent_id and returns the parent node
    Works with any storage backend — SQL, NoSQL, graph DB, etc.
    """
    # Build full path
    parts = []
    current = node
    while current is not None:
        parts.append(current.slug)
        parent_id = current.parent_id
        current = fetch_parent_fn(parent_id) if parent_id else None
    parts.reverse()
    full_path = "/" + "/".join(parts) + "/"

    # Compute depth
    depth = 0
    current = fetch_parent_fn(node.parent_id) if node.parent_id else None
    while current is not None:
        depth += 1
        current = fetch_parent_fn(current.parent_id) if current.parent_id else None

    # Build breadcrumbs
    crumbs = []
    current = node
    while current is not None:
        crumbs.append({"name": current.name, "path": current.full_path})
        current = fetch_parent_fn(current.parent_id) if current.parent_id else None
    crumbs.reverse()

    return {
        "full_path": full_path,
        "hierarchy_depth": depth,
        "breadcrumbs_data": crumbs
    }

Stick the full_path, hierarchy_depth and _breadcrumbs_data _right into the node record itself - so either add new columns to a database table or add new fields to a document store etc. Don't forget to index the _full_path _if you can.
At request time, the lookup becomes:

def handle_destination_request(full_path, db):
    node = db.fetch_by_indexed_field("full_path", full_path)
    # All derived data is pre-computed
    # Zero recursive queries. Zero parent traversal.
    return render(node)

When a request comes in looking for something, the lookup is now a super quick O(1) regardless of how deep down in the hierarchy the destination is. Whether that endpoint is buried two levels down or six, doesn't matter a bit.

The Cascading Update Problem

Precomputing slugs introduces a new headache : what happens when a parent node's slug gets changed? The result is that all of the descendants' _full_path _gets left behind.

The solution is to sort this out by making the system recompute downwards from the node whenever it gets updated. In a format that's easy to understand (but not code):

def on_node_saved(node, db, fetch_parent_fn):
    metadata = compute_node_metadata(node, fetch_parent_fn)
    db.update(node.id, metadata)

    # Propagate to all direct children
    children = db.fetch_children(node.id)
    for child in children:
        on_node_saved(child, db, fetch_parent_fn)
        # Recursion handles arbitrarily deep subtrees

In a framework with event hooks and all that jazz (post-save signals, lifecycle callbacks, database triggers), make sure this happens automatically as part of your persistence layer. If you're in a framework that doesn't have all that built in, just call it in your write path explicitly.

To be honest, changes to parent node slugs aren't all that common - hierarchies like Mexico or destinations begin to stabilise pretty quickly once you've set them up initially. So the cascading update is essentially a one-time cost every time you make an edit, not some huge overheard that's eating up resources with every request.

Legacy URL Handling

If you're adding hierarchical URLs to a system that used to just use flat slugs, you're going to need some kind of fallback. Existing pages that've been indexed under the old URL structure still need to be found:

def resolve_destination(path, db):
    # Try canonical hierarchical path first
    node = db.fetch_by_field("full_path", path)
    if node:
        return node

    # Fall back to legacy flat slug
    node = db.fetch_by_field("slug", path)
    if node and node.full_path != path:
        # Issue a permanent redirect to canonical URL
        return redirect_permanent(node.full_path)

    return not_found()

Legacy URLs redirect neatly to the actual hierarchical path. This means link equity is preserved, old indexed pages resolve correctly and you don't end up with duplicate content.

What This Gets You

By using the pre-computed approach you can take the complexity of your URLs off of your request-time performance. The full path for any destination, no matter how deep you go (or how big the hierarchy is) is just a single field read. Plus you can get breadcrumbs and depth information with zero extra queries. It doesn't matter if your backend is Django, Rails, Express or just some serverless function hitting a database - it all works the same way.

The catch is that there's a bit more complexity on the write side and you do need to deal with the cascading update thing. But if your content hierarchy isn't changing all that often, then the trade makes sense. Read performance is what scales as your traffic goes up, and a single field lookup is going to scale in a way that a recursive parent lookup just can't.

_
_

Building a Travel Portal in 2026: Our Story, Our Stack and Why We Are Still Here

MaxLJ — Mon, 20 Apr 2026 10:38:39 +0000

Hey Dev.to community 👋

We are the development team behind letsjourney.info - an independent travel deals and destination platform. We wanted to introduce ourselves and be honest about what building something like this actually looks like in 2026, because the reality is considerably messier than most startup introductions suggest.

How It Started

We launched as a fairly conventional affiliate portal. The idea was straightforward: aggregate travel deals from multiple provider APIs, build clean destination guides, drive organic traffic, collect affiliate commissions. Technically achievable. Business model proven by others.

Should work.
It worked, partially. The affiliate revenue model functions. The platform is live, it generates traffic, it produces commission income. But about 12 months in we started running into a problem that no affiliate tutorial had prepared us for: we were optimizing for the wrong thing.

We were optimizing for deal volume and page count. What we needed to be optimizing for was understanding why specific travelers search for specific things at specific times - and whether what we were surfacing actually matched that intent. The difference between those two approaches is the difference between a content farm and a useful platform.
So we started over. Not technically - Python infrastructure stayed, the API integrations stayed - but philosophically. The question shifted from "how do we add more deals" to "how do we understand what travelers actually need and build toward that."

The Stack and Why We Chose It

We are running Python on the backend with Wagtail CMS for content management. For anyone unfamiliar with Wagtail: it is a Django-based CMS that gives you the flexibility to build complex content hierarchies without the constraints of WordPress or the overhead of a custom-built system. For a travel portal that needs to manage multi-level destination hierarchy, structured deal models, vendor pages, coupon systems and editorial content all in the same codebase - it has been the right choice.
The API integration layer is the part that consumes the most engineering time by a significant margin. Multiple travel provider APIs each have different data schemas, different update frequencies, different rate limit behaviors, and different failure modes. Normalizing pricing data across heterogeneous sources - so that a deal card on the frontend shows accurate, current, comparable information regardless of which provider it came from - is an unsolved problem you solve incrementally. Every time you think you have it, a new edge case surfaces.

The 2026 Reality: Competing With the Whales

Booking.com has 28 million listings and a marketing budget we will never approach. Expedia Group owns approximately a dozen booking platforms simultaneously. *Google * has its own hotel and flight search products embedded directly in search results. Every organic travel search goes through an environment where these companies have built years of infrastructure to appear first.
Taking a meaningful share of that market as a small independent platform is not something we expect to do by being a better version of what they are. The approach that makes sense for a platform our size is being specifically useful to a specific traveler in a specific context - the US traveler planning a Cancun all-inclusive who wants an honest comparison rather than a ranked list shaped by which resort paid for placement, or the Bangkok first-timer who needs neighborhood-level hotel guidance rather than aggregate scores.
AI recommendation is part of how we are building toward this. Not AI in the sense of a chat interface that answers travel questions - but AI that informs how we surface deals, how we identify which destination content gaps matter most to fill, and how we understand where organic demand is moving before it peaks. Small platforms that can move fast on emerging travel trends have an advantage over large platforms with slow editorial cycles. That advantage only exists if you are actually reading the demand signals rather than publishing reactively.

What We Have Built So Far

The platform currently has several sections we consider reasonably mature:

Travel Deals - live deal aggregation across flights, hotels, vacation packages, cruise trips, car rentals, and travel insurance. The freshness problem (keeping displayed prices accurate against provider inventory that changes continuously) is the ongoing engineering challenge here.
Travel Coupons - verified discount codes across airlines, hotel chains, and tour operators. We verify codes manually before listing and remove expired ones within 24 hours. Slower than automated coupon aggregation, more reliable in practice.
Premium Coupons - we recently launched a dedicated premium coupon section, starting with Qatar Airways premium offers. This is a different product from the general coupons feed - curated, destination-specific, higher-value codes. It is an early version of what we want the coupon layer to become.
Hotel Reviews - independent editorial assessments of properties across Mexico, the Caribbean, Thailand, Dubai, and Europe. We built this because the gap between aggregate booking platform ratings and what travelers actually need to know is real and consequential. The update policy is the part we are most invested in: reviews get revised when properties change, not on a fixed calendar.

What We Are Building Next

The section we are actively developing is travel market analysis - demand trend tracking, seasonal pricing pattern documentation, emerging destination identification, and the kind of travel market intelligence that currently exists only inside the large OTAs and does not get published anywhere accessible to independent travelers or small travel businesses.
We are building the data pipeline for this now. The plan is to publish market analysis pieces on the platform itself and distribute them across our developer and travel community accounts: X at @letsjourneyinfo, Bluesky at letsjourney.bsky.social, and Medium. If you are interested in the intersection of travel data, API engineering, and demand analysis - those are the places to follow the work as it develops.

The Honest Part

Building an independent travel platform in 2026 is genuinely hard. Not primarily for technical reasons - the Python and Django stack handles the complexity well, the API integration problems are solvable, the AI tools are useful. It is hard because the market structure actively works against small independent platforms. The SEO environment, the paid acquisition costs, the API pricing from major travel data providers - all of these are calibrated for large operators and require creative approaches at small scale.
We are not under the illusion that we will compete with the large booking platforms. The goal is to build something specifically useful enough, and specifically honest enough, that the travelers who find it come back. That is a solvable problem at our scale in a way that general market share capture is not.
We will keep posting here as the platform develops - engineering challenges, architecture decisions, what the demand analysis tooling looks like as it comes together. If you are building in the travel or affiliate space, or working on similar API integration challenges, we would genuinely value the conversation.

More to come. 🌎