Saltar al contenido
Trabajo Prácticos
Referencias Técnicas

Referencias Técnicas

Este documento reúne conceptos técnicos que aparecen con frecuencia en la materia.

Arquitectura y diseño

Microservicios

En una arquitectura de microservicios, el sistema se divide en servicios pequeños que se pueden desplegar por separado. Cada servicio tiene una responsabilidad definida, administra sus datos y se comunica con los demás mediante contratos explícitos.

Domain-Driven Design (DDD)

Domain-Driven Design busca que el modelo de software refleje el dominio del negocio. Trabaja con conceptos como Bounded Contexts (límites del dominio), entidades, objetos de valor y lenguaje ubicuo.

API Gateway

Un API Gateway es el punto de entrada al sistema para los clientes. Puede encargarse del enrutamiento hacia los servicios backend, la validación de tokens y el rate limiting. Al agregarlo hay que considerar su efecto sobre el acoplamiento, la disponibilidad y la operación. Esas decisiones se pueden registrar en un ADR.

C4 Model

El modelo C4 documenta una arquitectura en cuatro niveles: contexto, contenedores, componentes y código. PlantUML y Structurizr son dos herramientas para crear estos diagramas.

Architecture Decision Records (ADR)

Un ADR es un documento breve sobre una decisión de diseño. Registra el problema, la decisión, las alternativas consideradas y sus consecuencias.

Mensajería en tiempo real y voz

WebSockets

WebSocket mantiene una conexión bidireccional entre el cliente y el servidor. A diferencia del modelo request/response de HTTP, cualquiera de los dos puede enviar datos mientras la conexión siga abierta. Se usa para mensajería en tiempo real y eventos de presencia.

Pub/Sub para mensajería distribuida

En Pub/Sub, los productores publican eventos en un topic sin conocer a los consumidores. Cada consumidor se suscribe a los temas que le interesan. Esto permite que varias instancias de un servicio compartan eventos aunque cada una mantenga sus propias conexiones con los clientes.

Las alternativas cambian según las garantías de entrega y persistencia que necesite el sistema:

  • RabbitMQ es un message broker con colas persistentes.
  • Amazon SQS es un servicio administrado de colas. Junto con SNS permite implementar fan-out hacia varias colas.
  • Redis Pub/Sub entrega mensajes de forma efímera. Si no hay suscriptores activos, el mensaje se pierde.
  • Kafka mantiene un log distribuido y durable que se puede releer. Esa persistencia también aumenta la complejidad operativa.

WebRTC

WebRTC permite intercambiar audio, video y datos en tiempo real entre navegadores o dispositivos. Se puede usar para canales de voz y videollamadas. La topología elegida cambia mucho su capacidad de escalar:

  • En una malla P2P, cada participante se conecta directamente con todos los demás. Funciona bien para una llamada entre dos personas, pero con N participantes requiere N·(N-1)/2 conexiones. Cada dispositivo termina enviando y recibiendo N-1 streams.
  • Una SFU (Selective Forwarding Unit) recibe el stream de cada participante y lo reenvía sin decodificarlo ni mezclarlo. Cada dispositivo mantiene una sola conexión con la SFU, por lo que esta topología se adapta mejor a grupos grandes.

También existe el modelo MCU, donde un servidor decodifica y mezcla todos los streams. Consume más recursos del servidor.

Una SFU puede contratarse como servicio, por ejemplo mediante LiveKit, Daily o Agora. Esto reduce la infraestructura propia. La otra posibilidad es operar una solución como mediasoup, lo que requiere resolver TURN/STUN para atravesar NAT, exponer puertos UDP y escalar el media server.

Para el cliente móvil, react-native-webrtc implementa las APIs de WebRTC en React Native. Su compatibilidad depende del flujo elegido, como Expo Go o bare workflow. En el navegador se puede usar la API WebRTC de MDN sin agregar una librería.

Referencias:

Resiliencia y patrones distribuidos

Saga Pattern

Una saga coordina una transacción que atraviesa varios servicios sin usar una transacción ACID global. Con coreografía, cada servicio reacciona a los eventos de los demás. Con orquestación, un coordinador dirige el flujo. Si una parte falla, las operaciones ya ejecutadas se revierten mediante acciones compensatorias.

Circuit Breaker

Circuit Breaker corta temporalmente las llamadas hacia un servicio que está fallando. En estado cerrado opera normalmente. Al abrirse, falla sin intentar la llamada. El estado semiabierto deja pasar algunas solicitudes para comprobar si el servicio se recuperó.

Retry con backoff exponencial

El backoff exponencial aumenta la espera entre intentos, por ejemplo 1, 2, 4 y 8 segundos. Sumar jitter evita que muchos clientes vuelvan a intentar al mismo tiempo. Este mecanismo sirve para operaciones idempotentes que fallan por una condición transitoria.

Idempotencia

Una operación es idempotente cuando repetirla produce el mismo resultado que ejecutarla una sola vez. Esto importa en pagos, cambios de inventario y emisión de eventos, porque cualquiera de esas operaciones puede reintentarse. Una forma común de detectar duplicados es guardar una idempotency key por request.

Fallos transitorios vs. permanentes

  • Un fallo transitorio puede resolverse sin intervención. Un timeout de red o un servicio momentáneamente caído son ejemplos. En estos casos se pueden aplicar reintentos y backoff.
  • Un fallo permanente necesita un cambio en los datos o alguna intervención. Credenciales inválidas y operaciones rechazadas entran en esta categoría. El sistema puede compensar el flujo o informar el error al usuario.

La clasificación evita reintentos que nunca van a funcionar y determina cómo recuperar el flujo.

Testing

Pirámide de tests

La pirámide agrupa los tests en tres niveles:

  1. Los tests unitarios validan la lógica de negocio de forma aislada.
  2. Los tests de integración validan la comunicación con dependencias y otros servicios.
  3. Los tests End-to-End (E2E) recorren flujos completos desde la entrada del sistema hasta el resultado observable.

Contract Testing

Los tests de contrato comprueban que dos servicios respeten el formato acordado. Sirven para detectar incompatibilidades sin levantar todo el sistema.

  • Pact sigue un enfoque consumer-driven: el consumidor define sus expectativas y el proveedor las verifica.
  • Schemathesis genera tests a partir de una especificación OpenAPI y los ejecuta contra el servicio.
  • Specmatic usa la especificación OpenAPI como contrato y también genera servicios virtuales.
  • oasdiff detecta cambios incompatibles entre versiones de una especificación.

Pruebas de carga y estrés (k6 / Artillery)

Las pruebas de carga miden el sistema bajo tráfico sostenido. Las de estrés aumentan la carga hasta encontrar sus límites. En ambos casos conviene registrar latencia (p50, p95 y p99), throughput y tasa de errores en los flujos críticos.

Mutation Testing

Mutation Testing introduce cambios pequeños en el código, llamados mutantes, y vuelve a correr los tests. Puede invertir una condición, cambiar un operador o modificar un valor límite. Si un test falla, el mutante muere. Si todos pasan, sobrevive: la suite ejecuta esa parte del código, pero no detecta que su comportamiento cambió. El mutation score es el porcentaje de mutantes muertos.

Como la suite se ejecuta muchas veces, el proceso puede ser lento. Por eso suele aplicarse a módulos concretos o en ejecuciones periódicas.

SAST (Static Application Security Testing)

SAST analiza el código fuente sin ejecutarlo para buscar vulnerabilidades. Se puede integrar al pipeline de CI. Bandit trabaja con Python, ESLint dispone de plugins de seguridad para Node.js y Semgrep soporta varios lenguajes.

Observabilidad

Health Checks

Los probes de liveness y readiness responden preguntas distintas. Un endpoint como /livez comprueba que el proceso siga vivo sin consultar servicios externos. /readyz indica si puede atender requests y normalmente revisa dependencias críticas, como la base de datos.

Logs estructurados

Los logs estructurados tienen un esquema estable y campos tipados. Es común codificarlos como JSON y clasificarlos por nivel, por ejemplo Error, Warn, Info o Debug.

Trazabilidad distribuida

Un trace ID o correlation ID identifica una operación mientras atraviesa varios servicios. Al propagarlo, las herramientas de observabilidad pueden relacionar requests, conexiones y eventos.

Prometheus y Grafana

Prometheus recolecta métricas de ejecución, como latencia, tasa de errores y uso de recursos. Los servicios pueden exponerlas mediante /metrics. Grafana las consulta y muestra en dashboards.

APIs y contratos

OpenAPI / Swagger

OpenAPI describe una API HTTP en un formato que pueden leer personas y herramientas. La especificación incluye endpoints, parámetros, cuerpos de request y response, esquemas y códigos de estado. También sirve para generar documentación y otras herramientas.

REST

REST es un estilo arquitectónico para sistemas distribuidos. En una API HTTP se expresa mediante recursos, una interfaz uniforme, métodos HTTP y códigos de estado con una semántica definida.

Frontend y mobile

React se usa para clientes web y React Native para aplicaciones móviles.

React

React es una biblioteca de JavaScript para construir interfaces declarativas basadas en componentes. Se puede combinar con un sistema de diseño o una librería de componentes.

React Native

React Native permite construir aplicaciones móviles nativas con React y compartir lógica entre Android e iOS. Expo simplifica la configuración. Un bare workflow da más control sobre los módulos nativos.

Electron

Electron empaqueta una aplicación web junto con Chromium y Node.js para ejecutarla como aplicación de escritorio. Además da acceso a funciones del sistema operativo, como notificaciones nativas o periféricos. Se puede reutilizar un cliente web, aunque Windows, macOS y Linux requieren configuraciones de build distintas.

Manejo de estado y datos del servidor

El estado global incluye datos como la sesión o las preferencias. Los datos que vienen de una API necesitan además caché, reintentos, invalidación y estados de carga o error.

Resiliencia en la capa de presentación

Una interfaz tiene que distinguir entre carga, error y latencia. También necesita mensajes útiles ante fallos de red y un comportamiento definido frente a timeouts. TanStack Query y SWR modelan estos estados y permiten configurar reintentos.

Gateway de pagos

Los gateways de pago exponen APIs para iniciar, confirmar y consultar pagos. Sus sandboxes permiten probar la integración sin procesar dinero real. Stripe y MercadoPago ofrecen documentación y entornos de prueba.

Stripe

Stripe tiene SDKs oficiales para distintos lenguajes, sandboxes y tarjetas predefinidas para simular resultados. Su API usa idempotency keys para evitar operaciones duplicadas.

MercadoPago

MercadoPago opera en Argentina y ofrece cuentas y tarjetas de prueba para simular distintos resultados.

Mobile y notificaciones

Firebase Cloud Messaging (FCM)

Firebase Cloud Messaging es el servicio de Google para enviar notificaciones push a Android, iOS y clientes web. El backend publica el mensaje y FCM se ocupa de entregarlo al dispositivo.

Seguridad y privacidad

Privacy by Design

Privacy by Design incorpora la protección de datos personales desde el diseño inicial. Esto incluye recolectar solo los datos necesarios, controlar el acceso a cada operación y no incluir información sensible en logs ni respuestas de error.