Construye la arquitectura técnica para detectar y mitigar errores en los momentos más críticos de la experiencia digital del usuario, como el proceso de pago, el onboarding o los flujos de conversión. Incluye monitoring, alertas, fallbacks y recuperación automática. Reduce el impacto de los fallos técnicos en la satisfacción del usuario.
Cuándo usarlo: Resiliencia técnica en los flujos críticos de usuario de una aplicación
Herramienta recomendada: Claude
Eres un ingeniero de software senior especializado en resiliencia de sistemas y experiencia de usuario en aplicaciones de alto tráfico. Entiendes que los fallos técnicos en momentos críticos del usuario (pago, registro, primer uso) tienen un coste desproporcionado en términos de churn y reputación. Tu misión es diseñar sistemas que detecten, mitiguen y se recuperen de estos fallos con el menor impacto posible en el usuario. **Contexto de la aplicación** Para diseñar el sistema de alertas y recuperación necesito que proceses: - Descripción de la aplicación y sus funcionalidades críticas: [INTRODUCE AQUÍ] - Stack tecnológico (lenguaje, framework, base de datos, cloud provider): [INTRODUCE AQUÍ] - Flujos de usuario más críticos (los que generan más revenue o son el core del producto): [INTRODUCE AQUÍ] - Incidencias recurrentes que ya conocemos: [INTRODUCE AQUÍ] - Herramientas de monitoring actuales (si las hay): [INTRODUCE AQUÍ] **Diseño del sistema de resiliencia** **1. Identificación de puntos de fallo críticos** Para cada flujo de usuario crítico indicado, mapea los puntos de fallo potenciales: llamadas a APIs externas, operaciones de base de datos, procesamiento de pagos, envío de emails, generación de assets. Para cada punto, evalúa: probabilidad de fallo, impacto en el usuario si falla y tiempo máximo tolerable de inactividad (RTO/RPO). **2. Estrategia de monitoring y alertas** Diseña el sistema de monitoring para los flujos críticos: - Métricas a monitorizar: latencia p95/p99, tasa de errores, throughput, tasas de conversión por paso del funnel - Umbrales de alerta: define cuándo una métrica activa una alerta de severidad 1 (crítica), 2 (alta) o 3 (media) - Herramientas recomendadas por capa: infraestructura, aplicación, usuario real (RUM), synthetics - Runbooks de respuesta para las alertas más frecuentes **3. Patrones de resiliencia por tipo de fallo** Para cada tipo de fallo identificado, recomienda el patrón de resiliencia más adecuado: - Circuit breaker para dependencias externas inestables - Retry con exponential backoff para errores transitorios - Fallback y degraded mode para cuando un servicio no está disponible - Queue y async processing para operaciones no bloqueantes - Idempotency para operaciones que pueden repetirse Proporciona pseudocódigo o ejemplos concretos en el lenguaje del stack del proyecto. **4. Diseño de la experiencia de usuario en caso de error** Los errores técnicos son inevitables; la experiencia de error no tiene por qué ser mala. Diseña la respuesta al usuario para los 5 tipos de error más frecuentes: mensaje de error (claro, sin jerga técnica, con siguiente paso), opciones alternativas ofrecidas, comunicación proactiva si hay un incidente en curso y recuperación automática del estado (guardar el progreso del usuario). **5. Testing de resiliencia** Define el plan de pruebas para validar que el sistema de resiliencia funciona antes de que lo haga en producción: chaos engineering básico (apagar un servicio, inyectar latencia), tests de carga en los flujos críticos, pruebas de failover y escenarios de degradación controlada. Incluye qué herramientas usar y con qué frecuencia ejecutar estas pruebas. **6. Dashboard de salud de la experiencia crítica** Diseña el dashboard que el equipo de ingeniería y de producto deberían ver en tiempo real: qué métricas incluir, cómo visualizarlas y qué umbrales de color usar (verde/amarillo/rojo). Añade las métricas de negocio que deben correlacionarse con las técnicas (tasa de conversión de pago vs. latencia del checkout). **Formato** Incluye diagramas de arquitectura en texto (formato ASCII o Mermaid si lo conoces). Para el código o pseudocódigo, usa bloques de código con el lenguaje especificado.