Why URL structure matters in a governed platform

URLs are more than navigation paths. In a modern digital platform, a URL communicates scope, ownership, access boundaries, and intent. It affects how users navigate, how developers reason about modules, how proxies and gateways enforce policy, and how logs and audits remain readable over time.

As platforms grow beyond single-tenant deployments into mixed models - public pages, private installations, and complete SaaS workspaces - a loose or inconsistent URL scheme becomes a liability. The upgrade to DYN (Dynamic Route) Microservicelets directly addresses this by bringing order, clarity, and scalability to URL design.

What is a Microservicelet (quick refresher)

A Microservicelet is a route-isolated functional module within the platform. Each microservicelet owns its routes, logic, permissions, and lifecycle, without requiring a fully separate service or deployment.

Routing is a first-class concern for microservicelets. The URL is the visible contract between the platform router and the microservicelet router. Getting this contract right is essential for modularity, governance, and long-term stability.

Microservicelet route types at a glance

The platform supports multiple route types, each serving a specific purpose:

  • Static route type: Fixed paths with no dynamic segments. Ideal for simple pages or dashboards with predictable navigation.
  • ID route type: Routes that include internal numeric identifiers. Common for tightly controlled internal resources.
  • UID route type: Routes that include stable unique identifiers suitable for sharing or bookmarking, without exposing internal IDs.
  • DYN (Dynamic) route type: Flexible, hierarchical routing where the microservicelet owns all path segments beyond a defined entry point. This enables modern, app-like URLs with deep nesting and a readable structure.
Microservicelet route types

DYN routes do not introduce a new type; they form the foundation of a modern URL infrastructure that scales across scopes and tenants.

Why DYN Microservicelets modernise URL infrastructure

DYN Microservicelets introduce a clean separation of responsibilities:

  • The platform router resolves scope and identity.
  • The microservicelet router resolves intent and structure within its domain.

This allows URLs to be:

  • Human-readable and predictable
  • Consistent across public, private, and SaaS deployments
  • Easy to reason about in logs, audits, and documentation
  • Flexible enough to support nested views, settings pages, workflows, and deep links

Most importantly, the same routing contract applies everywhere, regardless of deployment model.

URL Anatomy

URL Anatomy

The two core URL structures

At the heart of this upgrade are two clear and consistent URL patterns.

1. Global-scoped and platform-scoped microservicelet URLs

These URLs apply to:

  • Global-scoped pages: public or shared pages
  • Platform-scoped pages: private, non-SaaS deployments

Structure

{base_url}/{ms_name}/{route_name}/...

Examples

/wiki/page/architecture-overview
/insight/report/risk-summary
/flow/workflow/designer

How to read this

  • ms_name identifies the microservicelet
  • route_name identifies the entry route within that microservicelet
  • Everything after route_name is owned entirely by the microservicelet via DYN routing

This keeps the platform router simple and delegates structure to the module that best understands it.

2. Workspace-scoped microservicelet URLs (SaaS private pages)

These URLs apply to SaaS environments where multiple workspaces coexist on the same platform.

Structure

{base_url}/{prefix}/{space_slug}/{ms_name}/{route_name}/...

Examples

/w/acme/wiki/page/architecture-overview
/w/researchlab/flow/workflow/designer
/w/client01/insight/report/risk-summary

How to read this

  • prefix is a reserved namespace marker used by the platform router
  • space_slug defines the workspace boundary and aligns with identity and authorization
  • ms_name and route_name follow the same contract as global or platform scope
  • All remaining segments are resolved by the microservicelet

This structure makes workspace ownership explicit to both users and the system.

What this means for developers

For developers building or extending microservicelets, the DYN model brings clarity:

  • Route definitions focus on intent, not deployment scope
  • Microservicelets fully own their internal path hierarchy
  • Links are generated using route helpers rather than hardcoded paths
  • The same code works across public, private, and SaaS deployments

Deep routes like settings, editors, nested resources, or workflow steps no longer require special handling at the platform level.

What this means for administrators and integrators

For operations and governance teams, the benefits are equally tangible:

  • URLs clearly show which workspace and which module was accessed
  • Reverse proxy and gateway rules become simpler and safer
  • Audit logs remain readable and meaningful
  • Documentation and onboarding become easier, as patterns are consistent everywhere

The URL itself becomes a reliable source of truth.

Migration and compatibility

Existing Static, ID, and UID routes remain valid where appropriate. The shift to DYN routing follows a controlled migration path:

  • Inventory existing routes and scopes
  • Identify candidates for DYN conversion
  • Add redirects where needed
  • Update link generation to use route helpers
  • Monitor access logs for deprecated paths

This allows teams to adopt the new structure incrementally, without breaking existing users or integrations.

The bigger picture

DYN Microservicelets are not just a routing improvement. They establish a durable URL contract that supports:

  • Multi-tenant SaaS growth
  • Clean modular architecture
  • Strong governance and auditability
  • Long-term platform evolution without URL churn

By standardising how scope, identity, and intent appear in URLs, the platform gains a foundation that will hold as new studios, systems, and capabilities are added.