Curso de Microservicios con C# y .Net para equipos de desarrollo

Aplicar pensamiento DDD para descubrir dominios, subdominios, bounded contexts, reglas de negocio y responsabilidades naturales.

Separar capacidades de negocio en servicios que tengan sentido funcional, no solo en entidades técnicas como “clientes”, “pedidos” o “facturas”.

Identificar límites incorrectos cuando varios servicios necesitan cambiar juntos, compartir datos internos o coordinar despliegues constantemente.

Diseñar mapas de contexto con relaciones upstream, downstream, customer-supplier, conformist, shared kernel y anti-corruption layer.

Definir ownership de servicio: equipo responsable, repositorio, base de datos, SLO, backlog, documentación, incidentes y decisiones de evolución.

Evitar que los microservicios repliquen la estructura organizativa de forma ciega cuando esa organización ya genera silos o fricción.

Revisar cómo el lenguaje ubicuo ayuda a que contratos, eventos, endpoints y nombres de servicios sean comprensibles para negocio y desarrollo.

Separar dominios core, supporting y generic para decidir dónde invertir más diseño, calidad y autonomía.

Preparar workshops de modelado con Event Storming, mapas de capacidades y análisis de flujos de negocio.

Documentar boundaries mediante ADRs, diagramas C4, ejemplos de contratos, reglas de datos y decisiones de ownership.

Diseñar una solución inicial con varios servicios ASP.NET Core, workers, librerías compartidas controladas, contratos y pruebas independientes.

Organizar repositorios según estrategia: monorepo, multirepo o repositorios híbridos, evaluando ownership, CI/CD, visibilidad y complejidad.

Separar proyectos por API, aplicación, dominio, infraestructura, contratos, tests y adaptadores externos cuando el servicio lo justifique.

Definir convenciones de naming para servicios, namespaces, endpoints, eventos, colas, bases de datos, imágenes y despliegues.

Crear servicios con plantillas corporativas que incluyan logging, health checks, OpenAPI, autenticación, configuración y testing base.

Evitar librerías compartidas que introducen acoplamiento oculto entre servicios y bloquean despliegues independientes.

Diseñar librerías transversales pequeñas para concerns realmente comunes: observabilidad, errores, seguridad, configuración o contracts.

Preparar una estructura de solución que permita crecimiento sin convertir cada servicio en una copia desordenada del anterior.

Definir documentación mínima por servicio: propósito, owner, contratos, dependencias, datos, runbooks, SLOs y despliegue.

Crear un estándar técnico de microservicio .NET que sirva como referencia para nuevos equipos y revisiones de arquitectura.

Construir APIs con ASP.NET Core usando controllers o minimal APIs según complejidad, estilo del equipo y necesidades de mantenibilidad.

Diseñar endpoints con contratos claros, códigos HTTP correctos, validación, errores coherentes y semántica estable.

Usar OpenAPI para documentar contratos, facilitar consumo, generar clientes y apoyar contract testing.

Separar DTOs públicos, modelos de dominio, entidades de persistencia y eventos para evitar fugas de implementación.

Implementar validación de entrada con reglas explícitas, mensajes seguros y respuesta consistente ante errores de negocio.

Diseñar APIs idempotentes cuando la operación puede repetirse por reintentos, fallos de red o integración con otros sistemas.

Aplicar versionado de APIs cuando existen consumidores externos, frontends desacoplados o contratos con ciclo de vida propio.

Preparar endpoints administrativos internos para health, metrics, readiness, diagnóstico y mantenimiento controlado.

Evitar APIs demasiado genéricas que exponen operaciones internas en lugar de capacidades de negocio claras.

Crear una guía de diseño de APIs .NET para microservicios con ejemplos correctos, anti-patrones y criterios de revisión.

Comprender gRPC como framework RPC de alto rendimiento e independiente del lenguaje, soportado en .NET para comunicación entre servicios.

Diseñar contratos `.proto` claros, versionables y estables, evitando filtrar modelos internos del dominio.

Crear servicios gRPC con ASP.NET Core y clientes .NET preparados para entornos distribuidos.

Comparar REST y gRPC según latencia, streaming, compatibilidad, tooling, consumo externo, depuración y necesidades de interoperabilidad.

Implementar unary calls, server streaming, client streaming y bidirectional streaming cuando el caso de negocio lo justifique.

Gestionar errores gRPC con status codes, metadata, detalles seguros y traducción adecuada hacia consumidores.

Configurar autenticación, autorización, TLS, deadlines, cancellation tokens, retries y circuit breakers en clientes gRPC.

Incorporar gRPC client factory para gestionar clientes, configuración, resiliencia y dependencias de forma mantenible.

Probar contratos gRPC con escenarios de compatibilidad, cambios de schema, mensajes obligatorios y consumidores simulados.

Definir criterios corporativos para decidir cuándo un microservicio debe exponer REST, gRPC, eventos o una combinación controlada.

Diseñar llamadas HTTP entre servicios con `HttpClientFactory`, clientes tipados, timeouts explícitos y manejo de errores.

Evitar cadenas de llamadas síncronas donde un endpoint depende de varios servicios y multiplica latencia, errores y acoplamiento.

Aplicar patrones de resiliencia como retries limitados, circuit breakers, bulkheads, fallback y políticas diferenciadas por dependencia.

Propagar correlation IDs y trace context para seguir una petición entre varios servicios durante diagnóstico e incidentes.

Gestionar errores parciales cuando un servicio dependiente no responde, responde tarde o devuelve información incompleta.

Diseñar respuestas degradadas cuando el usuario puede continuar con funcionalidad limitada sin caída completa del sistema.

Evitar compartir modelos internos entre cliente y servidor cuando eso convierte cualquier cambio en una ruptura distribuida.

Crear clientes de servicio encapsulados, testables y con configuración centralizada.

Medir latencia, tasa de error, saturación, timeouts y retries por dependencia para detectar degradaciones.

Documentar dependencias síncronas con owner, SLO esperado, contrato, timeout, fallback y estrategia de recuperación.

Diseñar comunicación asíncrona para desacoplar servicios, absorber picos, mejorar resiliencia y evitar bloqueos innecesarios.

Diferenciar comandos, eventos de dominio, eventos de integración, mensajes técnicos, notificaciones y tareas diferidas.

Comparar RabbitMQ, Apache Kafka, Azure Service Bus, AWS SQS/SNS y otros brokers según caso, escala, orden, retención y operación.

Crear publicadores y consumidores en .NET con manejo de errores, reintentos, dead letter queues y observabilidad.

Diseñar eventos con semántica clara, versión, idempotencia, correlation ID, causation ID y datos suficientes para consumidores.

Evitar eventos gigantes, ambiguos o demasiado acoplados al modelo interno de un servicio.

Gestionar mensajes duplicados, desordenados, tardíos o incompletos sin romper reglas de negocio.

Definir ownership de topics, exchanges, colas, subscriptions, schemas y consumidores.

Medir lag, throughput, errores, reintentos, DLQ, tiempo de procesamiento y frescura de datos.

Crear una estrategia de mensajería empresarial con estándares de naming, versionado, seguridad, trazabilidad y soporte.

Evaluar Dapr como runtime distribuido que expone building blocks mediante APIs HTTP o gRPC para resolver retos comunes de microservicios.

Comprender el modelo sidecar de Dapr, donde cada servicio se comunica con su runtime local para usar componentes de infraestructura.

Aplicar service invocation para llamadas entre servicios sin acoplar el código a direcciones físicas concretas.

Usar pub/sub de Dapr para publicar y consumir eventos con abstracción sobre brokers como Redis, RabbitMQ, Kafka o servicios cloud.

Evaluar state management, bindings, secrets, actors, workflows y configuration según necesidades reales del sistema.

Comparar Dapr frente a librerías nativas, SDKs cloud y patrones implementados directamente en .NET.

Diseñar componentes Dapr por entorno, separando desarrollo local, integración, staging y producción.

Gestionar resiliencia, observabilidad, seguridad y configuración dentro del modelo Dapr.

Evitar usar Dapr como solución mágica cuando el equipo no entiende los patrones distribuidos que encapsula.

Crear un laboratorio con varios microservicios .NET comunicados mediante Dapr, pub/sub y estado externo.

Utilizar Aspire como herramienta de orquestación local y observabilidad para modelar, ejecutar, depurar y conectar aplicaciones distribuidas.

Crear un AppHost que describa servicios .NET, bases de datos, caches, colas, dependencias y relaciones entre recursos.

Ejecutar varios microservicios en local con configuración coherente, variables, endpoints, dependencias y trazabilidad.

Usar el dashboard de Aspire para revisar logs, trazas, métricas, dependencias y estado de recursos durante desarrollo.

Comprender que Aspire no sustituye al framework de aplicación, al cloud provider ni al runtime de producción, según la propia documentación.

Integrar servicios ASP.NET Core, workers, PostgreSQL, Redis, RabbitMQ, SQL Server u otros recursos en un entorno local reproducible.

Diseñar proyectos para que el onboarding de nuevos desarrolladores sea más rápido y con menos configuración manual.

Comparar Aspire con docker compose, Kubernetes local y scripts propios de desarrollo.

Evitar dependencias ocultas entre servicios gracias a la visibilidad de la topología local.

Crear una plantilla de solución distribuida con Aspire, observabilidad base y buenas prácticas de configuración.

Diseñar un API Gateway como punto de entrada para routing, autenticación, agregación, rate limiting, observabilidad y control de tráfico.

Evaluar cuándo usar API Gateway, Backend for Frontend, reverse proxy, service mesh o acceso directo a servicios.

Usar YARP como reverse proxy altamente personalizable para .NET, diseñado para crear soluciones de proxy flexibles y escalables.

Configurar rutas, clusters, destinos, transforms, health checks y políticas de proxy con YARP.

Diseñar BFFs para frontends web, móviles o backoffice, evitando que los clientes conozcan la topología interna de microservicios.

Gestionar autenticación, autorización, tokens, cookies, CORS, cabeceras y propagación de identidad en el gateway.

Evitar gateways que acumulan lógica de negocio y se convierten en un nuevo monolito central.

Añadir rate limiting, circuit breaking, caching, logging y trazabilidad en el borde de la arquitectura.

Crear pruebas para rutas, autorización, transforms, errores y degradación del gateway.

Definir criterios para decidir qué debe vivir en gateway, BFF, servicio de dominio o frontend.

Aplicar el principio de base de datos por servicio para mantener autonomía, ownership y evolución independiente.

Evitar compartir tablas entre microservicios, aunque parezca más cómodo para reporting, joins o integraciones rápidas.

Diseñar persistencia según necesidades de cada servicio: relacional, documental, clave-valor, búsqueda, cache o event store.

Gestionar cambios de schema con migraciones versionadas, despliegues compatibles y rollback planificado.

Separar modelo de dominio, modelo de persistencia, DTOs, eventos y modelos de lectura.

Crear estrategias de sincronización entre servicios mediante eventos, proyecciones, materialized views o APIs controladas.

Gestionar datos duplicados de forma intencionada, documentada y reconciliable, no como copia accidental.

Diseñar ownership de datos con criterios de escritura, lectura, historificación, retención y privacidad.

Medir salud de bases de datos por latencia, locks, errores, conexiones, crecimiento, saturación y consultas críticas.

Documentar decisiones de persistencia mediante ADRs, incluyendo trade-offs de consistencia, rendimiento, coste y operación.

Comprender por qué las transacciones distribuidas suelen ser problemáticas en microservicios y cuándo deben evitarse.

Diseñar consistencia eventual explicando claramente qué ve el usuario, qué estados intermedios existen y cómo se recuperan errores.

Implementar patrón Outbox para publicar eventos de forma fiable después de cambios de base de datos locales.

Aplicar patrón Inbox para deduplicar mensajes recibidos y proteger consumidores frente a reentregas.

Diseñar Sagas coreografiadas u orquestadas para procesos largos como pedidos, pagos, reservas, aprovisionamiento o facturación.

Crear compensaciones de negocio cuando un paso posterior falla y no existe rollback técnico simple.

Gestionar estados intermedios, timeouts, reintentos, cancelaciones y reconciliación manual.

Evitar sagas demasiado opacas donde nadie entiende quién coordina, qué estados existen o cómo se recuperan fallos.

Probar procesos distribuidos con escenarios de fallo en cada paso, duplicados, mensajes tardíos y dependencias caídas.

Documentar flujos de consistencia con diagramas de secuencia, eventos, estados, compensaciones y responsabilidades.

Diseñar endpoints y consumidores capaces de procesar peticiones repetidas sin crear efectos secundarios duplicados.

Usar idempotency keys para operaciones críticas como pagos, pedidos, reservas, altas, importaciones o cambios de estado.

Gestionar duplicados de mensajes mediante claves, tablas de procesamiento, ventanas temporales y control de estado.

Diferenciar entre idempotencia técnica y reglas de negocio que determinan si una operación puede repetirse.

Controlar concurrencia con optimistic concurrency, locks razonables, versiones de agregado o restricciones de base de datos.

Crear respuestas consistentes cuando una operación ya se ejecutó pero el cliente no recibió confirmación.

Diseñar reintentos seguros para APIs, workers y consumidores de eventos.

Preparar métricas de duplicados, reintentos, conflictos, compensaciones y operaciones parcialmente completadas.

Probar idempotencia con fallos simulados de red, timeouts, reentregas y ejecución concurrente.

Documentar operaciones críticas con sus invariantes, riesgos, estrategias de recuperación y criterios de auditoría.

Diseñar autenticación y autorización entre servicios usando OAuth2, OpenID Connect, JWT, mTLS o identidades gestionadas según entorno.

Separar autenticación de usuario final, identidad de servicio, permisos internos y autorización por recurso.

Propagar contexto de usuario solo cuando sea necesario, evitando exponer información sensible en cabeceras o eventos.

Aplicar mínimos privilegios en APIs internas, colas, bases de datos, secretos, observabilidad y herramientas de despliegue.

Gestionar secretos con vaults, variables protegidas, rotación, scopes y prohibición de credenciales en repositorios.

Diseñar políticas de autorización por servicio, operación, tenant, entorno y sensibilidad del dato.

Revisar riesgos de seguridad típicos: SSRF, exposición de endpoints internos, tokens largos, logs sensibles y permisos amplios.

Proteger comunicación mediante TLS, certificados, gateways, service mesh o controles equivalentes cuando la arquitectura lo requiera.

Crear auditoría de acciones críticas entre servicios, especialmente en cambios de permisos, pagos, datos personales o administración.

Integrar seguridad en CI/CD, code review, threat modeling y pruebas de integración.

Gestionar configuración por entorno sin duplicar valores manualmente ni mezclar settings de desarrollo, staging y producción.

Separar configuración técnica, configuración de negocio, secretos, flags, límites de resiliencia y parámetros operativos.

Usar `IOptions`, configuración tipada, validación al arranque y fallos tempranos cuando falta configuración crítica.

Proteger secretos mediante Azure Key Vault, AWS Secrets Manager, HashiCorp Vault, Kubernetes Secrets u opciones corporativas.

Diseñar feature flags para separar despliegue de activación funcional y reducir riesgo en releases.

Controlar flags por entorno, usuario, tenant, porcentaje, grupo o criterio de negocio.

Evitar flags permanentes que se convierten en deuda y multiplican ramas lógicas dentro del código.

Registrar cambios de configuración sensibles con auditoría, owner, motivo y fecha.

Probar configuración en CI/CD para detectar errores antes de desplegar.

Crear una estrategia de configuración distribuida con seguridad, trazabilidad, rollback y documentación.

Instrumentar microservicios .NET con logs estructurados, métricas, trazas distribuidas y correlation IDs.

Usar OpenTelemetry para recoger señales estándar y exportarlas a herramientas como Prometheus, Grafana, Jaeger, Tempo, Azure Monitor o equivalentes.

Comprender que .NET integra APIs de logging, métricas y Activity que sirven como base para OpenTelemetry.

Diseñar convenciones de nombres para spans, métricas, atributos, eventos y dimensiones de negocio.

Propagar contexto de traza entre HTTP, gRPC, colas, eventos, workers y dependencias externas.

Evitar cardinalidad excesiva en métricas por IDs únicos, usuarios, payloads o valores demasiado variables.

Crear dashboards por servicio, journey, dependencia, cola, base de datos y SLO.

Detectar problemas de latencia, errores, saturación, timeouts, retries, colas acumuladas y dependencias degradadas.

Proteger datos sensibles en logs y trazas, evitando payloads completos, tokens, cookies, datos personales o secretos.

Definir una plantilla de observabilidad obligatoria para cada microservicio antes de pasar a producción.

Implementar health checks en ASP.NET Core para reportar estado de aplicación, base de datos, colas, cache y dependencias.

Diferenciar liveness, readiness y startup checks para evitar reinicios innecesarios o tráfico hacia servicios no preparados.

Crear checks rápidos, seguros y útiles, sin sobrecargar dependencias críticas con pruebas demasiado costosas.

Exponer endpoints internos de salud con información suficiente para orquestadores y limitada para públicos externos.

Integrar health checks con Kubernetes, balanceadores, gateways, monitorización y pipelines postdeploy.

Diseñar estados degradados cuando una dependencia no crítica falla pero el servicio puede operar parcialmente.

Añadir información de build, versión, commit, entorno y configuración no sensible para facilitar soporte.

Crear runbooks asociados a fallos de health check para que el equipo sepa qué revisar y cómo mitigar.

Evitar health checks que devuelven OK aunque el servicio no pueda cumplir su función principal.

Definir criterios de producción: ningún servicio crítico se despliega sin health checks, métricas, logs, trazas y owner.

Diseñar servicios preparados para fallos de red, latencia alta, dependencias caídas, timeouts, saturación y errores parciales.

Aplicar retries con backoff y jitter para evitar tormentas de reintentos ante dependencias degradadas.

Usar circuit breakers para cortar llamadas temporalmente cuando una dependencia falla de forma sostenida.

Aplicar bulkheads para aislar recursos y evitar que una operación lenta bloquee todo el servicio.

Diseñar fallbacks que permitan devolver datos parciales, cacheados o mensajes claros sin romper la experiencia completa.

Establecer timeouts explícitos y coherentes entre cliente, gateway, servicio, base de datos y mensajería.

Medir retries, timeouts, circuit breaker state, fallbacks y degradaciones como señales operativas.

Evitar resiliencia mal configurada que oculta fallos reales o aumenta presión sobre sistemas ya saturados.

Probar resiliencia con fallos simulados de dependencias, colas, bases de datos y servicios externos.

Documentar políticas de resiliencia por dependencia con owner, parámetros, motivo y límites.

Diseñar una estrategia de pruebas que combine unitarias, integración, contrato, componente, end-to-end y pruebas de resiliencia.

Crear tests unitarios para dominio, servicios de aplicación, validadores, mappers, políticas y reglas de negocio.

Usar tests de integración con bases reales en contenedores, APIs de prueba y configuración aislada.

Aplicar contract testing para validar compatibilidad entre consumidores y proveedores sin desplegar todo el sistema.

Crear pruebas de componente que levanten un servicio con dependencias simuladas o contenedores controlados.

Evitar end-to-end excesivos que se vuelven lentos, frágiles y difíciles de diagnosticar.

Probar escenarios distribuidos: duplicados, mensajes tardíos, dependencia caída, timeout, error parcial y reintento.

Integrar Testcontainers, WireMock, mocks HTTP, brokers de laboratorio y datos sintéticos.

Medir cobertura útil por reglas críticas, contratos, flujos de negocio e invariantes, no solo por porcentaje.

Crear una pirámide de testing específica para microservicios .NET con criterios de CI/CD.

Crear Dockerfiles multi-stage para servicios .NET con imágenes pequeñas, seguras, reproducibles y adecuadas a producción.

Usar imágenes base oficiales, usuario no root, capas optimizadas, variables claras y puertos documentados.

Diferenciar imágenes de desarrollo, pruebas, debugging y producción.

Publicar servicios .NET como contenedores aprovechando capacidades actuales del SDK cuando el flujo del equipo lo permita.

Controlar configuración, certificados, secretos, timezone, cultura, health checks y dependencias externas dentro del contenedor.

Reducir tamaño de imagen mediante trimming, runtime images, limpieza de capas y exclusión de archivos innecesarios.

Analizar vulnerabilidades de imágenes, paquetes y dependencias antes de publicar.

Etiquetar imágenes con versión, commit, entorno, fecha y metadatos relevantes.

Probar contenedores localmente con redes, bases de datos, colas y servicios simulados.

Crear estándares de contenedorización para APIs, workers, gateways y procesos batch .NET.

Desplegar servicios .NET en Kubernetes usando Deployments, Services, ConfigMaps, Secrets, Ingress y probes.

Configurar requests y limits de CPU y memoria según pruebas de carga, perfiles de consumo y objetivos de fiabilidad.

Definir readiness, liveness y startup probes alineadas con health checks reales de ASP.NET Core.

Gestionar variables de entorno, configuración, secretos, certificados y diferencias entre entornos.

Diseñar escalado horizontal con HPA basado en CPU, memoria, latencia, colas o métricas custom.

Diagnosticar problemas habituales: CrashLoopBackOff, OOMKilled, errores de probes, imágenes incorrectas y fallos de red.

Integrar logs, métricas y trazas de contenedores con la plataforma de observabilidad.

Aplicar políticas de seguridad: usuario no root, network policies, RBAC, image scanning y mínimos privilegios.

Gestionar despliegues rolling, canary, blue-green y rollback con criterios de validación.

Crear una guía de operación Kubernetes para microservicios .NET con comandos, dashboards y runbooks.

Diseñar pipelines que compilan, prueban, analizan, empaquetan, escanean y despliegan servicios .NET de forma repetible.

Separar validaciones rápidas de pull request y validaciones profundas de release o cambios críticos.

Publicar artefactos versionados: imágenes Docker, paquetes NuGet, manifiestos, Helm charts, documentación y contratos.

Aplicar quality gates sobre tests, seguridad, cobertura crítica, contratos API, migraciones y análisis estático.

Diseñar despliegues progresivos con canary, blue-green, feature flags, smoke tests y validaciones postdeploy.

Preparar rollback técnico y funcional antes de desplegar, especialmente cuando hay migraciones de datos o contratos nuevos.

Controlar secretos, service connections, permisos de pipeline, environments y aprobaciones manuales.

Integrar CI/CD con observabilidad para detectar automáticamente degradación tras release.

Documentar cada pipeline con owner, triggers, variables, secretos, entornos, permisos y procedimiento de fallo.

Medir eficacia de entrega con lead time, frecuencia de despliegue, tasa de fallo, MTTR y estabilidad de releases.

Revisar dependencias NuGet, imágenes de contenedor, actions de CI/CD, SDKs, librerías internas y herramientas de build.

Aplicar dependency scanning, secret scanning, SAST, container scanning y revisión de licencias cuando la empresa lo requiera.

Fijar versiones de dependencias críticas y establecer política de actualización, revisión y retirada.

Evitar paquetes abandonados, sin mantenimiento, con licencias incompatibles o con historial de vulnerabilidades relevantes.

Crear SBOM cuando el entorno corporativo o regulatorio requiere trazabilidad de componentes.

Proteger repositorios, ramas, paquetes, registries, claves de firma, tokens y pipelines de publicación.

Revisar acciones de GitHub, tareas de pipeline o scripts externos antes de permitir ejecución en CI/CD.

Gestionar parches de seguridad con priorización por explotabilidad, exposición, criticidad del servicio y mitigación disponible.

Documentar excepciones y riesgos aceptados con owner, fecha de revisión y controles compensatorios.

Integrar seguridad de supply chain en la Definition of Done de cada microservicio.

Evaluar si el monolito actual debe modularizarse, dividirse, encapsularse, reescribirse parcialmente o mantenerse con mejoras internas.

Identificar seams de extracción mediante análisis de dominios, tablas, flujos, dependencias, cambios frecuentes y problemas operativos.

Aplicar estrategia Strangler Fig para rodear el monolito con nuevas capacidades sin parar el negocio.

Crear anti-corruption layers para proteger nuevos servicios de modelos, reglas y estructuras heredadas.

Extraer primero capacidades de bajo riesgo o alto valor, evitando empezar por el núcleo más complejo sin pruebas suficientes.

Diseñar convivencia entre monolito y microservicios con routing, eventos, sincronización de datos, autenticación y observabilidad.

Crear pruebas de caracterización antes de mover comportamiento crítico.

Gestionar migraciones de datos con doble escritura, backfill, reconciliación, validación y rollback.

Comunicar fases, riesgos, métricas y criterios de éxito a negocio, arquitectura, desarrollo y operaciones.

Medir avance por menor acoplamiento, despliegues más seguros, reducción de deuda, tiempo de cambio y estabilidad del sistema.

Analizar rendimiento de APIs, workers, consumidores de eventos, gateways y bases de datos bajo carga realista.

Medir latencia p50, p95, p99, throughput, errores, saturación, consumo de CPU, memoria, conexiones y colas.

Diseñar escalado por servicio, no por aplicación completa, aprovechando la granularidad de microservicios cuando aporta valor.

Revisar cuellos de botella en serialización, consultas, llamadas remotas, locks, colas, cache y dependencias externas.

Aplicar caching local, distribuido o por gateway con criterios de invalidez, seguridad y consistencia.

Preparar pruebas de carga, estrés, soak y resiliencia antes de eventos, campañas o releases críticos.

Establecer capacity planning con headroom, límites conocidos, umbrales y acciones preventivas.

Evitar escalado horizontal que solo oculta problemas de base de datos, contratos o diseño de comunicación.

Integrar métricas de rendimiento en dashboards, alertas y decisiones de arquitectura.

Definir performance budgets por endpoint, servicio, proceso batch, cola o journey de usuario.

Definir SLIs y SLOs por servicio, endpoint, flujo de negocio, cola, job o dependencia crítica.

Usar error budgets para equilibrar velocidad de entrega y estabilidad operativa.

Crear alertas basadas en síntomas de usuario, burn rate, latencia, errores y disponibilidad, no solo en CPU o memoria.

Diseñar runbooks por servicio con dashboards, comandos, síntomas, mitigación, escalado y validación final.

Gestionar incidentes con roles, severidades, comunicación, timeline, mitigación y postmortem blameless.

Reducir toil mediante automatización de tareas repetitivas, reinicios, escalados, diagnósticos y validaciones.

Conectar incidentes con deuda técnica, decisiones de arquitectura, falta de observabilidad o pipelines frágiles.

Medir MTTD, MTTA, MTTR, recurrencia, impacto, error budget consumido y acciones preventivas cerradas.

Preparar revisiones periódicas de SLOs, alertas, runbooks, deuda operativa y fiabilidad.

Crear cultura de ownership donde cada equipo desarrolla, despliega, observa y mejora sus propios servicios.

Diseñar un sistema distribuido con varios microservicios .NET, API Gateway, mensajería, persistencia propia, workers y contratos documentados.

Definir bounded contexts, ownership, repositorios, bases de datos, eventos, APIs, responsabilidades y límites de cada servicio.

Construir APIs ASP.NET Core y al menos un servicio gRPC o integración síncrona con resiliencia, timeouts y trazabilidad.

Implementar comunicación asíncrona con broker, eventos de integración, consumidores, Outbox, idempotencia y dead letter handling.

Configurar .NET Aspire para desarrollo local con servicios, bases, colas, observabilidad y dependencias modeladas.

Contenerizar servicios con Docker, configuración por entorno, health checks y ejecución local reproducible.

Preparar despliegue Kubernetes o equivalente con probes, secrets, config, escalado y manifiestos controlados.

Crear pipelines CI/CD con tests, contract testing, análisis de seguridad, build de imágenes, despliegue y rollback.

Instrumentar logs, métricas, trazas, dashboards, alertas, SLOs y runbooks para soporte operativo.

Presentar arquitectura final con ADRs, diagramas, decisiones, trade-offs, riesgos, deuda pendiente y roadmap de evolución.