3 de junio de 2026
9 min de lectura
Arquitectura de logística en ecommerce: múltiples paqueterías sin acoplar el sistema
Cómo diseñar la capa de envíos de un ecommerce para soportar múltiples paqueterías, cambiar de proveedor sin romper nada y seleccionar la mejor opción en runtime.
Read in EnglishEl costo de acoplarse a una sola paquetería
Muchos ecommerce empiezan integrando directamente la API de una sola paquetería. Eso funciona al inicio, pero el acoplamiento aparece pronto: cuando la paquetería no tiene cobertura en una zona, cuando sus tarifas dejan de ser competitivas o cuando el SLA no se cumple. Cambiar requiere reescribir la integración, no solo actualizar una configuración.
El problema no es usar una paquetería; es que el código de negocio conozca los detalles de esa paquetería. Si la lógica de cotización, generación de guías y rastreo está distribuida por el sistema con llamadas directas al SDK de un proveedor específico, el costo de cambiar es alto y el de agregar una alternativa es aún más alto.
El patrón de puerto y adaptador aplicado a logística
La solución es definir una interfaz de shipping provider que el sistema de pedidos conoce, y luego implementar un adaptador por cada paquetería real. La interfaz define qué puede hacer un proveedor de envíos: cotizar, generar guía, cancelar guía y consultar estado. Cada adaptador implementa esa interfaz con las llamadas específicas de su API.
Con esa separación, agregar una paquetería nueva es implementar un adaptador nuevo sin tocar el sistema de pedidos. Cambiar el proveedor por defecto es cambiar qué adaptador se inyecta en runtime, no reescribir lógica de negocio. El sistema de pedidos solo habla con la interfaz.
Interfaz de shipping provider y uso en el servicio de pedidos.
interface ShippingRate {
carrierId: string;
carrierName: string;
service: string;
price: number;
estimatedDays: number;
}
interface ShippingProvider {
getRates(params: QuoteParams): Promise<ShippingRate[]>;
createLabel(params: LabelParams): Promise<Label>;
cancelLabel(trackingNumber: string): Promise<void>;
getTrackingStatus(trackingNumber: string): Promise<TrackingEvent[]>;
}
// El servicio de pedidos solo conoce la interfaz
class OrderFulfillmentService {
constructor(private shipping: ShippingProvider) {}
async shipOrder(order: Order) {
const rates = await this.shipping.getRates({
from: order.warehouseAddress,
to: order.shippingAddress,
parcel: order.parcel,
});
const best = rates.sort((a, b) => a.price - b.price)[0];
return this.shipping.createLabel({ rate: best, order });
}
}Selección de paquetería en runtime
Con múltiples adaptadores disponibles, la lógica de selección de paquetería puede vivir en un router que recibe las cotizaciones de todos los proveedores y elige la mejor según criterios configurables: precio más bajo, entrega más rápida, disponibilidad para la zona destino o proveedor preferido por el cliente.
Este router puede evolucionar sin tocar el resto del sistema. Hoy puede elegir por precio; mañana puede considerar el historial de incidentes por zona o la hora del día. Esa flexibilidad es el resultado de haber separado la selección del proveedor de la integración con el proveedor.
- Define criterios de selección como configuración, no como código hardcodeado.
- Registra qué proveedor se usó por pedido para analizar performance y costos.
- Implementa un fallback: si el proveedor preferido falla, usa el siguiente.
Rastreo unificado y notificaciones al cliente
El rastreo es el caso de uso donde el modelo de proveedor abstracto más ayuda. Cada paquetería tiene sus propios estados (en camino, en ruta, entregado, intento fallido) con nombres distintos. El adaptador traduce esos estados a un enum interno del sistema, y el sistema siempre trabaja con ese enum, no con los strings del proveedor.
Las notificaciones al cliente (email, SMS, push) se disparan sobre eventos internos, no sobre eventos de la paquetería. Cuando el adaptador recibe un webhook y lo convierte a un evento interno `ShipmentDelivered`, el sistema de notificaciones reacciona a ese evento sin saber qué paquetería lo originó.
Más artículos
Volver a artículosPlataformas de pago en México: Stripe, Conekta, Mercado Pago y OpenPay
Comparativa técnica y comercial de las cuatro plataformas más usadas para aceptar pagos en proyectos digitales mexicanos.
3 de junio de 2026
7 min de lectura
Plataformas de envíos en México: Skydropx, EnviosPerros, Pakke y Enviame
Cómo elegir entre los principales agregadores de paquetería para ecommerce en México según volumen, operación y necesidades técnicas.
3 de junio de 2026
7 min de lectura
CMS headless en 2026: PayloadCMS, Strapi, Sanity y Directus
Qué CMS headless elegir según el tipo de proyecto, el control técnico que necesitas y cómo planeas modelar el contenido.
3 de junio de 2026
8 min de lectura