DEV Community: Edgardo Genini

[EN] Delegated Resource Identifier (DRI): a pattern for persistent references in microservices

Edgardo Genini — Wed, 13 May 2026 01:39:17 +0000

If you've ever stored a URL in a database and later regretted it, this is for you.

It's a familiar scenario: a service needs to keep a reference to a resource that lives in another service. The obvious solution is to store the URL. It works — until the host changes, the API gets a new version, or the team decides to restructure the paths. Suddenly all the stored references are broken, and tracking down the impact becomes a bigger problem than it should be.

The root issue is that a URL mixes two different things: what the resource is and where it lives. When you store a URL, you're betting that location won't change. In systems that evolve, that's usually a losing bet.

The idea

What if instead of storing where the resource lives, you store your own identifier that a gateway knows how to resolve?

commerce:orders/order:id=ARG-2024-00091872
finance:accounts/customer:status:id=109234
health:coverage/credential:patient-id=12345678

Whoever stores the reference doesn't need to know where the resource lives or how to access it. That's the gateway's responsibility. If the API changes, if the service migrates, if a new system appears: only the resolver changes. The stored references remain valid.

I called this scheme Delegated Resource Identifier (DRI).

What this pattern is not

It's not a standard
It requires a gateway as intermediary: it doesn't apply when the client needs to access the resource directly without going through any intermediary
It doesn't impose a context taxonomy: each team defines their own

It's a useful convention when you need persistent references to resources in a controlled ecosystem and want to centralize the resolution logic.

How it's built

The identifier has two parts separated by /:

<context>/<resource>

Context (left side): identifies the domain that knows how to resolve this type of resource. The gateway uses it for routing.
Resource (right side): identifies the concrete resource. Its structure is defined by whoever implements the resolver.

commerce:orders/order:id=ARG-2024-00091872
└─── routing ───┘└─── concrete resource ──┘

: separates hierarchical levels. = assigns values. Each side defines its own internal convention.

The identifier is built by whoever stores the reference, from the data they already have and the context they know. No external call required. A billing service that receives an order ID knows it belongs to commerce:orders and builds the DRI when persisting the reference.

The context can be omitted if the gateway has a default resolver:

/order:id=ARG-2024-00091872

Some use cases

E-commerce: retrieving an order

A customer service system stores references to orders that can come from different channels: own store, marketplace, mobile app. Each channel has its own API.

commerce:orders/order:id=ARG-2024-00091872
commerce:orders/order:id=MKT-2024-00034521

The commerce:orders resolver determines which channel each order belongs to based on the ID prefix and routes to the corresponding API. The identifier remains stable even if the channel's API changes.

Fintech: customer account status

A bank with legacy and modern systems running side by side. The resolver determines which system the customer lives in based on the ID value: customers with id < 50000 are in the legacy system, the rest in the modern one.

finance:accounts/customer:status:id=109234
finance:accounts/customer:status:id=002871

The resolver also encapsulates the decision of which API version to use. And here something interesting emerges: the DRI has two moments in its lifecycle. When persisted, it's just the identifier. When used for a query, it can be enriched with additional context using the same syntax:

finance:accounts/customer:status:id=109234:date=20260101

The resolver can use that date to determine which API version applies. The persisted DRI doesn't change; the additional context is added at query time.

Health: member coverage credential

A member's coverage can change over time: provider migration, gaps in coverage, or coverage with more than one provider. Storing the provider as a fixed value would produce outdated references.

health:coverage/credential:patient-id=12345678

The resolver applies a fallback strategy: it queries the first available provider and if the credential isn't found, tries the next one. The DRI resolves at query time, always reflecting the current state.

Multinational with tenant: supplier by legal entity

A SaaS platform used by a company operating in multiple countries. Each country has its own supplier management system, its own API, and its own tax identifier format.

tenant:acme:ar/supplier:cuit=20123456789
tenant:acme:cl/supplier:rut=76354921-5
tenant:acme:mx/supplier:rfc=XYZ123456789

The left side combines tenant and legal entity by country. The right side respects the local convention without the gateway knowing anything about it. Adding a new subsidiary or tenant means registering an additional resolver, without touching existing references. The context hierarchy grows naturally with the system.

How the gateway works

The resolution flow is simple: the gateway receives the identifier, extracts the context, and delegates to the corresponding resolver.

client  →  gateway  →  resolver(commerce:orders)  →  actual service

Receives the identifier
Extracts the context (left side)
Delegates to the registered resolver for that context
The resolver fetches the resource and returns the response

The gateway has no knowledge of concrete resources. As an orientative reference, a possible Java implementation:

gateway.register("commerce:orders",   new OrderResolver());
gateway.register("finance:accounts",  new AccountResolver());
gateway.register("health:coverage",   new CoverageResolver());

public interface ResourceResolver {
    Response resolve(ResourceIdentifier identifier);
}

Optional preferences

The identifier supports expressing preferences about how the resource should be resolved, with a syntax inspired by HTTP's Accept header. For example, when querying available payment methods, you can indicate a preference for debit over credit:

payments:methods/available:customer:id=109234;debit,q=0.9;credit,q=0.7

The meaning of q is defined by the contract between whoever builds the reference and whoever resolves it. The gateway doesn't need to interpret it. This capability is completely optional.

I implemented this in Java and found it useful in practice. If you try it in your own context or have ideas to improve it, I'd love to read them in the comments.

[ES] Delegated Resource Identifier (DRI): un patrón para referencias persistentes en microservicios

Edgardo Genini — Wed, 13 May 2026 01:36:45 +0000

También disponible en Inglés

Si alguna vez guardaste una URL en una base de datos y después te arrepentiste, esto es para vos.

Es un escenario conocido: un servicio necesita mantener una referencia a un recurso que vive en otro servicio. La solución más obvia es guardar la URL. Funciona, hasta que el host cambia, la API sube de versión, o el equipo decide reestructurar los paths. De repente todas las referencias guardadas están rotas, y rastrear el impacto se convierte en un problema mayor de lo que debería ser.

El problema de fondo es que una URL mezcla dos cosas distintas: qué es el recurso y dónde está. Cuando guardás una URL estás apostando a que esa ubicación no va a cambiar. En sistemas que evolucionan, esa apuesta suele perderse.

La idea

¿Qué pasaría si en lugar de guardar dónde está el recurso, guardás un identificador propio que un gateway sabe cómo resolver?

comercio:pedidos/orden:id=ARG-2024-00091872
finanzas:cuentas/cliente:estado:id=109234
salud:cobertura/credencial:patient-id=12345678

Quien guarda la referencia no necesita saber dónde vive el recurso ni cómo se accede. Esa responsabilidad la tiene el gateway. Si la API cambia, si el servicio migra, si aparece un sistema nuevo: solo cambia el resolver. Las referencias guardadas siguen siendo válidas.

A este esquema lo llamé Delegated Resource Identifier (DRI).

Lo que este patrón no es

No es un estándar
Requiere un gateway como intermediario: no aplica cuando el cliente necesita acceder directamente al recurso sin pasar por ningún intermediario
No impone una taxonomía de contextos: cada equipo define la suya

Es una convención útil cuando necesitás referencias persistentes a recursos en un ecosistema controlado, y querés centralizar la lógica de resolución.

Cómo se construye

El identificador tiene dos partes separadas por /:

<contexto>/<recurso>

Contexto (lado izquierdo): identifica el dominio que sabe resolver este tipo de recurso. El gateway lo usa para rutear.
Recurso (lado derecho): identifica el recurso concreto. Su estructura la define quien implementa el resolver.

comercio:pedidos/orden:id=ARG-2024-00091872
└─── ruteo ──────┘└─── recurso concreto ──┘

Los : separan niveles jerárquicos. El = asigna valores. Cada lado define su propia convención interna.

El identificador lo construye quien guarda la referencia, a partir del dato que ya tiene y el contexto que conoce. No requiere ninguna llamada externa. Un servicio de facturación que recibe el ID de una orden sabe que pertenece a comercio:pedidos y construye el DRI al momento de persistir la referencia.

El contexto puede omitirse si el gateway tiene un resolver por defecto:

/orden:id=ARG-2024-00091872

Algunos casos de uso

E-commerce: recuperar una orden

Un servicio de atención al cliente guarda referencias a órdenes que pueden venir de distintos canales: tienda propia, marketplace, app móvil. Cada canal tiene su propia API.

comercio:pedidos/orden:id=ARG-2024-00091872
comercio:pedidos/orden:id=MKT-2024-00034521

El resolver de comercio:pedidos determina a qué canal pertenece cada orden a partir del prefijo del ID y rutea hacia la API correspondiente. El identificador es estable aunque la API del canal cambie.

Fintech: estado de cuenta de un cliente

Un banco con sistemas legacy y modernos conviviendo. El resolver determina en qué sistema vive el cliente según el valor del ID: clientes con id < 50000 en el sistema legacy, el resto en el moderno.

finanzas:cuentas/cliente:estado:id=109234
finanzas:cuentas/cliente:estado:id=002871

El resolver encapsula también la decisión de qué versión de la API usar. Y acá aparece algo interesante: el DRI tiene dos momentos de vida. Cuando se persiste es solo el identificador. Cuando se usa para consultar, puede enriquecerse con contexto adicional usando la misma sintaxis:

finanzas:cuentas/cliente:estado:id=109234:fecha=20260101

El resolver puede usar esa fecha para determinar qué versión de la API corresponde. El DRI persistido no cambia; el contexto adicional se agrega en el momento de la consulta.

Salud: credencial de cobertura de un afiliado

La cobertura de un afiliado puede cambiar en el tiempo: migración de proveedor, períodos sin cobertura, cobertura en más de uno. Guardar el proveedor como dato fijo generaría referencias desactualizadas.

salud:cobertura/credencial:patient-id=12345678

El resolver aplica una estrategia de fallback: consulta al primer proveedor disponible y si no encuentra la credencial prueba con el siguiente. El DRI resuelve en el momento de la consulta, reflejando siempre el estado actual.

Multinacional con tenant: proveedor por entidad legal

Una plataforma SaaS con operaciones en múltiples países. Cada país tiene su propio sistema, su propia API y su propio formato de identificador fiscal.

tenant:acme:ar/proveedor:cuit=20123456789
tenant:acme:cl/proveedor:rut=76354921-5
tenant:acme:mx/proveedor:rfc=XYZ123456789

El lado izquierdo combina tenant y entidad legal por país. El lado derecho respeta la convención local. Agregar una nueva filial o un nuevo tenant es registrar un resolver adicional, sin tocar las referencias existentes. La jerarquía del contexto crece naturalmente con el sistema.

Cómo funciona el gateway

El flujo de resolución es simple: el gateway recibe el identificador, extrae el contexto y delega al resolver correspondiente.

cliente  →  gateway  →  resolver(comercio:pedidos)  →  servicio real

Recibe el identificador
Extrae el contexto (lado izquierdo)
Delega al resolver registrado para ese contexto
El resolver obtiene el recurso y devuelve la respuesta

El gateway no conoce recursos concretos. A modo de referencia orientativa, una posible implementación en Java:

gateway.register("comercio:pedidos", new OrderResolver());
gateway.register("finanzas:cuentas", new AccountResolver());
gateway.register("salud:cobertura",  new CoverageResolver());

public interface ResourceResolver {
    Response resolve(ResourceIdentifier identifier);
}

Preferencias opcionales

El identificador admite expresar preferencias sobre cómo debe resolverse el recurso, con una sintaxis inspirada en el header Accept de HTTP. Por ejemplo, al consultar medios de pago se puede indicar preferencia por débito sobre crédito:

pagos:medios/disponibles:cliente:id=109234;debito,q=0.9;credito,q=0.7

El significado de q lo define el contrato entre quien construye la referencia y quien la resuelve. El gateway no necesita interpretarlo. Esta capacidad es completamente opcional.

Lo implementé en Java y me resultó útil en la práctica. Si lo probás en tu contexto o tenés ideas para mejorarlo, me interesa leerlo en los comentarios.