1. Comunicación y Contenido Técnico

# ❌ MAL (asume conocimiento)
"Usa un circuit breaker para manejar fallos en servicios downstream."

# ✅ BIEN (explica desde cero)
"Cuando tu servicio llama a otro servicio (ej: API de pagos), ese servicio puede fallar.
Si falla repetidamente, tu servicio puede quedar bloqueado esperando respuestas.

Un circuit breaker es un patrón que detecta cuando un servicio está fallando mucho
y automáticamente deja de llamarlo por un tiempo, devolviendo un error inmediato.
Es como un fusible eléctrico que se corta cuando hay sobrecarga.

Ejemplo con código:
[código completo con comentarios]"

# ✅ BIEN (directo, trade-offs, referencias)
"Implementamos circuit breaker con estado distribuido en Redis (vs in-memory)
para consistencia cross-instance, a costa de latency adicional (~5ms p99).

Trade-offs considerados:
- In-memory: Más rápido pero inconsistente en multi-instance
- Redis: Consistente pero latency adicional
- Consensus (etcd): Fuerte consistencia pero complejidad operacional

Elegimos Redis por balance latency/consistencia. Para casos donde 5ms es crítico,
considerar in-memory con eventual consistency.

Ref: [Hystrix design](https://github.com/Netflix/Hystrix/wiki)"

# ✅ BIEN (impacto de negocio, analogía simple)
"Problema: Cuando el servicio de pagos falla, nuestro checkout se queda esperando
hasta 30 segundos, lo que causa que usuarios abandonen la compra.

Solución: Implementamos un 'fusible automático' que detecta cuando pagos está fallando
y devuelve error inmediato, permitiendo al usuario reintentar o usar otro método de pago.

Impacto:
- Reducción de 30s → 100ms en tiempo de respuesta cuando pagos falla
- Estimamos 15% menos abandono de carrito en incidentes (basado en data histórica)
- Mejor experiencia de usuario en escenarios de fallo"

# ✅ BIEN (executive summary, métricas, recomendación)
## Propuesta: Migración a Microservicios

**Recomendación:** Migrar gradualmente de monolito a microservicios en 18 meses.

**Impacto de Negocio:**
- Velocidad: 2x deployment frequency (1/semana → 2/semana)
- Costo: Reducción 30% en cloud costs (mejor utilización de recursos)
- Riesgo: Reducción 50% en downtime (fallos aislados, no cascada)

**Inversión:**
- 4 engineers x 18 meses = $800K
- Cloud migration costs = $200K
- Total: $1M

**ROI:** Payback en 14 meses (ahorro en cloud + reducción de downtime)

**Riesgos:**
- Complejidad operacional (mitigación: contratar SRE)
- Curva de aprendizaje (mitigación: training + external consultants)

# Post-Mortem: Outage de Pagos (2015)

## Hook
El 15 de enero, nuestro sistema de pagos estuvo down por 2 horas durante Black Friday,
resultando en $120K de revenue perdido y 500+ tickets de soporte.

## Context
- Sistema de pagos: Monolito Java + PostgreSQL
- Tráfico normal: 100 TPS, Black Friday: 500 TPS (5x)
- Deployment reciente: Nueva feature de descuentos (deployed 2 días antes)

## Challenge
A las 10:00 AM, latency de pagos aumentó de 200ms → 30s. A las 10:15, DB connections
pool exhausted, causando cascading failures en todo el sistema.

## Root Cause
Nueva feature de descuentos ejecutaba N+1 queries (1 query por producto en carrito).
Con 5x tráfico, DB no pudo manejar la carga.

## Solution (Immediate)
- 10:30: Rollback de feature de descuentos
- 10:45: Sistema recuperado, latency normal

## Solution (Long-term)
- Refactor: Batch queries (1 query para todos los productos)
- Monitoring: Alertas en latency p99 >1s y DB connection pool >80%
- Load testing: Simular Black Friday traffic antes de deployments

## Outcome
- Downtime: 2 horas
- Revenue perdido: $120K
- Lecciones aprendidas: [ver sección siguiente]

## Lessons
1. **Load testing es crítico**: Simular tráfico real antes de eventos de alto tráfico
2. **Monitoring proactivo**: Detectar degradación antes de outage completo
3. **Feature flags**: Deploy features críticas detrás de flags para rollback rápido

# RFC-042: Migración a Microservicios

## Context
Sistema monolítico con 500K LOC, 10 años de legacy, deployment frequency 1/semana...

## Proposal
Migración gradual usando strangler pattern:
1. Identificar bounded contexts
2. Extraer servicios uno a uno
3. Routing dual (monolito + microservicio)
4. Deprecar código en monolito

## Trade-offs
- Pros: Deployment frequency, fault isolation, scalability
- Cons: Operational complexity, distributed tracing, data consistency

# Cómo Migramos de Monolito a Microservicios Sin Downtime

Hace 2 años, nuestro sistema era un monolito de 500K líneas de código.
Deployments tomaban 2 horas y cualquier bug afectaba todo el sistema.

Hoy, tenemos 15 microservicios, deployamos 10 veces por semana y downtime
se redujo 80%. Acá te cuento cómo lo hicimos.

## El Problema
[Hook con problema concreto]

## La Estrategia: Strangler Pattern
[Explicar patrón con analogía]

## Paso a Paso
[Proceso simplificado]

## Resultados
[Métricas de impacto]

## Lecciones Aprendidas
[3-5 takeaways accionables]

[HOOK - Problema o resultado sorprendente]

[CONTEXTO - 2-3 líneas]

[SOLUCIÓN - Qué hiciste, cómo]

[RESULTADO - Métricas concretas]

[LECCIÓN - 1-2 takeaways]

[CTA - Pregunta o invitación a comentar]

#hashtag1 #hashtag2 #hashtag3

Redujimos el tiempo de deployment de 2 horas a 15 minutos. 🚀

Hace 6 meses, cada deployment era un evento. Todo el equipo en call,
dedos cruzados, y 2 horas de tensión.

Implementamos:
→ CI/CD automatizado (GitHub Actions)
→ Blue-green deployments
→ Automated rollback en <2min

Resultado:
✅ Deployment time: 2h → 15min
✅ Deployment frequency: 1/semana → 5/semana
✅ Failed deployments: 20% → 2%

Lección: Automatización no es solo velocidad, es confianza.
Cuando deployment es fácil, deployamos más seguido, con menos riesgo.

¿Cuál es tu mayor pain point en deployments?

#DevOps #CI/CD #SoftwareEngineering

1/ [HOOK + Promesa]
Ejemplo: "Aprendí 5 lecciones migrando a microservicios que me hubiera gustado saber antes. 🧵"

2/ [Lección 1]

3/ [Lección 2]

...

N/ [Resumen + CTA]
Ejemplo: "Resumen: [3 bullets]. ¿Qué agregarías? 💬"

# ❌ MAL (título genérico)
"Cómo Mejorar tu Sistema"

# ✅ BIEN (keywords específicas)
"Cómo Migrar de Monolito a Microservicios con Spring Boot: Guía Completa 2024"
Keywords: migrar monolito microservicios, spring boot microservices, microservices tutorial

# Technical Writing Style Guide

## Tono
- **Claro y directo**: Evitar ambigüedad
- **Profesional pero accesible**: No formal en exceso
- **Activo vs pasivo**: Preferir voz activa ("Implementamos X" vs "X fue implementado")

## Estructura
- **Pirámide invertida**: Información más importante primero
- **Párrafos cortos**: 2-4 líneas máximo
- **Listas**: Usar bullets para >3 items
- **Headings**: Jerarquía clara (H1 → H2 → H3)

## Código
- **Syntax highlighting**: Siempre especificar lenguaje
- **Comentarios**: Explicar el "por qué", no el "qué"
- **Ejemplos completos**: No snippets sin contexto
- **Runnable**: Código debe ser ejecutable (o indicar que es pseudocódigo)

## Ejemplos
- **Concretos**: Casos de uso reales, no abstractos
- **Relevantes**: Relacionados al dominio del lector
- **Completos**: Incluir setup, ejecución, output esperado

## Anti-patterns
- ❌ Jerga sin explicar
- ❌ Asumir conocimiento previo (sin indicarlo)
- ❌ Ejemplos abstractos (foo, bar, baz)
- ❌ Código sin contexto
- ❌ Párrafos >10 líneas

# [Título con Keywords]

## Hook (1 párrafo)
[Problema relevante o resultado sorprendente]

## Context (2-3 párrafos)
[Situación, por qué importa, para quién es relevante]

## Problem (3-4 párrafos)
[Descripción detallada del problema, ejemplos concretos]

## Solution (5-10 párrafos)
[Cómo lo resolviste, paso a paso, con código/diagramas]

### Paso 1: [Título]
[Explicación + código]

### Paso 2: [Título]
[Explicación + código]

## Results (2-3 párrafos)
[Métricas, impacto, comparación antes/después]

## Trade-offs (2-3 párrafos)
[Qué sacrificaste, cuándo NO usar esta solución]

## Lessons Learned (3-5 bullets)
- [Lección 1]
- [Lección 2]
- [Lección 3]

## Conclusion (1 párrafo)
[Resumen + CTA]

## References
- [Link 1]
- [Link 2]