Lección 16 de 20 · Lectura y práctica
Diseñar la arquitectura de servicios para un e-commerce
Concepto claveDiseñar una arquitectura de servicios para un e-commerce con gRPC implica descomponer el dominio en servicios acoplados débilmente que se comunican mediante contratos tipados. Piensa en un centro comercial: cada.
Del concepto a la práctica
Taller de esta lección
Una arquitectura útil asigna una responsabilidad y una fuente de verdad a cada servicio. En una librería, inventario decide existencias, pedidos conserva el estado del pedido y pagos solo registra el intento simulado; ninguno debe editar directamente la información de otro.
Ejemplo resuelto
Cliente -> Pedidos: crear
Pedidos -> Inventario: reservar
Pedidos -> Pagos: autorizar_simulado
Pedidos -> Cliente: confirmado o rechazadoPedidos coordina el flujo, pero no inventa stock ni confirma un pago que falló.
Para completar el rechazo usa SKU BK-7, stock2 y pedido42 con cantidad3; registra ausencia de llamada a Pagos, no solo estado del cliente. Catálogo, si lo añades, conserva precios unitarios; Inventario conserva unidades y reservas, y Pedidos conserva el importe acordado en el momento de crear el pedido. Todos los pagos de este laboratorio son simulados.
Pruébalo
Dibuja las tres llamadas y los datos mínimos de cada una.
Marca qué servicio puede modificar cada dato.
Añade una respuesta para reserva insuficiente y otra para pago rechazado.
Error frecuente: compartir una tabla o mensaje mutable entre todos los servicios. Corrección: define contratos de entrada y respuesta, y conserva la autoridad dentro de cada servicio.
Comprueba tu resultado
Ejercicio: usa 2 unidades disponibles y solicita 3. Resultado esperado: Inventario rechaza la reserva, Pedidos no solicita el pago y el cliente recibe un estado de rechazo trazable.

Mapa de prácticaUna condición decide qué camino ejecuta el programa. Un bucle repite una operación mientras queden elementos, y termina cuando la lista se agota. Separar ambas ideas ayuda a seguir el flujo y comprobar casos límite.
Ver la infografía en tamaño completo ↗Concepto clave
Diseñar una arquitectura de servicios para un e-commerce con gRPC implica descomponer el dominio en servicios acoplados débilmente que se comunican mediante contratos tipados. Piensa en un centro comercial: cada tienda (servicio) tiene su propia especialidad (productos, pagos, inventario), pero todas siguen reglas comunes (Protocol Buffers) para interactuar. gRPC actúa como el sistema de mensajería interno que garantiza que los pedidos entre tiendas sean rápidos y sin errores.
La clave está en definir interfaces claras usando Protocol Buffers, que sirven como contrato entre servicios. Esto evita que cambios en un servicio rompan otros, similar a cómo un contrato legal protege a ambas partes en un negocio. Para un e-commerce, servicios como Catálogo, Carrito, Pagos, y Envíos deben operar de forma independiente pero coordinada, usando gRPC para llamadas síncronas (como verificar stock) y streams para datos en tiempo real (como notificaciones de pedidos).
Cómo funciona en la práctica
Imagina que un usuario agrega un producto al carrito. Primero, el servicio Frontend llama al servicio Carrito via gRPC para agregar el ítem. El servicio Carrito, a su vez, llama al servicio Catálogo para validar el precio y disponibilidad. Aquí, Protocol Buffers define los mensajes, por ejemplo:
message AddToCartRequest {
string user_id = 1;
string product_id = 2;
int32 quantity = 3;
}
message AddToCartResponse {
bool success = 1;
string message = 2;
double total_price = 3;
}Paso a paso: 1) Define los archivos .proto para cada servicio, especificando métodos y mensajes. 2) Genera código en tu lenguaje (ej., Go o Java) usando el compilador protoc. 3) Implementa servidores gRPC que expongan estos métodos. 4) Configura clientes en otros servicios para llamar a estos métodos. 5) Usa middleware para manejar logs, métricas y retries, asegurando resiliencia.
Caso de estudio
Considera un e-commerce con 1 millón de usuarios diarios. Desglosamos en servicios:
| Servicio | Responsabilidad | gRPC Métodos Clave |
|---|---|---|
| Catálogo | Gestionar productos y precios | GetProduct, ListProducts, UpdateStock |
| Carrito | Manejar carritos de compra | AddItem, RemoveItem, Checkout |
| Pagos | Procesar transacciones | ProcessPayment, Refund |
| Envíos | Gestionar logística | CreateShipment, TrackOrder |
Ejemplo concreto: Cuando un usuario finaliza una compra, el servicio Carrito llama a Pagos via gRPC con un mensaje ProcessPaymentRequest. Si el pago es exitoso, Carrito notifica a Envíos para crear un envío, usando un stream gRPC para actualizaciones en tiempo real. Esto reduce la latencia a milisegundos vs. REST, crucial para alta concurrencia.
En pruebas, gRPC mostró un 60% menos de latencia que REST para 10,000 solicitudes concurrentes en un entorno de e-commerce.
Errores comunes
- Definir mensajes .proto demasiado grandes: Esto acopla servicios y dificulta evoluciones. Solución: Mantén mensajes pequeños y usa imports para reutilizar definiciones comunes.
- Ignorar el manejo de errores en gRPC: gRPC usa códigos de estado (ej., NOT_FOUND, INTERNAL), pero muchos devs no los mapean correctamente. Implementa interceptores para traducir errores de negocio a códigos gRPC apropiados.
- No planificar versiones de Protocol Buffers: Cambiar un campo .proto puede romper clientes. Usa reglas como no eliminar campos y marcar obsoletos con reserved.
- Olvidar timeouts y retries: En microservicios, las fallas de red son comunes. Configura timeouts específicos por método y usa políticas de retry con backoff exponencial.
- Sobrecargar servicios con lógica de negocio cruzada: Ej., poner lógica de inventario en el servicio Carrito. Mantén responsabilidades claras para evitar acoplamiento.
Checklist de dominio
- ¿Definiste archivos .proto separados por servicio con mensajes y servicios claros?
- ¿Implementaste servidores gRPC con manejo de errores usando códigos de estado estándar?
- ¿Configuraste clientes gRPC con timeouts, retries y balanceo de carga?
- ¿Usaste streams gRPC para casos como notificaciones en tiempo real?
- ¿Integraste middleware para observabilidad (logs, métricas, tracing)?
- ¿Probaste la interoperabilidad entre servicios en diferentes lenguajes?
- ¿Documentaste las APIs gRPC generadas para otros equipos?
Diseñar e implementar un servicio de carrito con gRPC
En este ejercicio, crearás un servicio de carrito para un e-commerce usando gRPC y Protocol Buffers. Sigue estos pasos:
- Define el contrato .proto: Crea un archivo cart.proto con un servicio CartService que incluya métodos como AddItem, RemoveItem, y GetCart. Define mensajes como CartItem y CartResponse, usando tipos apropiados (ej., string para user_id, int32 para quantity).
- Genera el código: Usa el compilador protoc para generar código en tu lenguaje preferido (ej., Go, Java, o Python). Asegúrate de incluir opciones para gRPC.
- Implementa el servidor: Crea un servidor gRPC que maneje los métodos definidos. Por ejemplo, en AddItem, valida la cantidad y calcula el precio total llamando a un servicio simulado de catálogo.
- Crea un cliente de prueba: Implementa un cliente que llame a AddItem con datos de ejemplo (ej., user_id="123", product_id="prod_abc", quantity=2) y muestre la respuesta.
- Añade resiliencia: Configura timeouts de 5 segundos para las llamadas y un retry policy con 3 intentos para fallas temporales.
- Prueba la integración: Ejecuta el servidor y cliente, verificando que las respuestas sean correctas y los errores se manejen adecuadamente.
Pistas
- Usa el paquete google.golang.org/grpc si trabajas en Go para simplificar la implementación.
- Para simular el servicio de catálogo, puedes crear un mock que devuelva un precio fijo, como 29.99.
- Considera usar un mapa en memoria para almacenar los carritos por user_id en el servidor, pero recuerda que en producción necesitarías una base de datos.
Evalua tu comprension
Completa el quiz interactivo de arriba para ganar XP.
Sigue con Implementación Avanzada de gRPC y Protocol Buffers para Microservicios
Esta lección forma parte de un curso de Cursalo. Revisa su programa y elige entre la compra individual o el acceso a toda la escuela.
Si ya tenías acceso a este curso, entra con tu cuenta: tus derechos y tu progreso se conservan. No necesitas comprarlo de nuevo.