01
| Área | Tema Específico | Objetivo | Dif. | Recursos | Proyecto / Validación | Criterio de Éxito |
|---|---|---|---|---|---|---|
| Principios SOLID |
SOLID: los cinco principios con ejemplos de violación y corrección
SRP · OCP · LSP · ISP · DIP · God class antipattern · tight coupling · cohesión alta vs baja · refactoring hacia SOLID
|
Reconocer cuándo una clase o módulo acumula responsabilidades que, con el tiempo, hacen que los cambios tengan efectos secundarios inesperados — la raíz de la mayoría del código heredado problemático. | Fácil | Tomar un módulo de facturación con una God Class de 500 líneas y refactorizarlo en clases con responsabilidad única, extensibles por OCP e inyección de dependencias. Demostrar que agregar un nuevo tipo de descuento no modifica código existente. | PythonAñadir un nuevo tipo de descuento sin modificar clases existentes; cada clase con una única razón de cambio documentada; suite de tests que no cambia al agregar el nuevo tipo; diagrama UML antes/después del refactor. | |
| Patrones de Diseño |
GoF Creacionales: Factory Method, Abstract Factory, Builder y Singleton
Factory Method vs Abstract Factory · Builder para objetos complejos · Singleton con thread safety · problemas del Singleton global · inyección de dependencias como alternativa
Principios SOLID (DIP como base de los creacionales)
|
Desacoplar la creación de objetos de su uso para que los componentes no dependan de implementaciones concretas — fundamento de cualquier sistema que necesite ser testeable y extensible. | Fácil | Sistema de notificaciones con Abstract Factory que crea familias (Email/SMS/Push) de forma intercambiable; Builder para construir Notification con configuración opcional; Singleton thread-safe para el pool de conexiones. |
PythonAgregar canal WhatsApp sin modificar código cliente; Builder previene objetos con estado inválido; Singleton devuelve la misma instancia bajo 100 threads concurrentes verificado con test; tests sin dependencias reales. | |
| Patrones de Diseño |
GoF Estructurales: Adapter, Decorator, Facade y Proxy
Adapter para integraciones legacy · Decorator para cross-cutting concerns · Facade para subsistemas complejos · Proxy para lazy loading y access control · composición sobre herencia
Patrones creacionales + SOLID (OCP, LSP)
|
Componer comportamientos complejos a partir de piezas simples sin herencia profunda — la base de middlewares, interceptors y capas de integración que aparecen en todo sistema backend real. | Medio | API client con Adapter que envuelve 3 SDKs de pago diferentes; Decorator que añade logging, caching y rate limiting sin modificar el cliente; Facade que simplifica el subsistema de pagos a 3 métodos públicos. | PythonCódigo cliente usa los 3 SDKs con la misma interfaz; decoradores componibles en cualquier orden; Facade reduce acoplamiento verificado con análisis de imports; cada patrón documentado con diagrama y justificación. | |
| Patrones de Diseño |
GoF de Comportamiento: Observer, Strategy, Command y Template Method
Observer para eventos desacoplados · Strategy para algoritmos intercambiables · Command para operaciones reversibles · Template Method para flujos con variantes · diferencia Observer vs Pub/Sub
Patrones estructurales + SOLID (OCP, DIP)
|
Modelar comportamientos que varían independientemente de la estructura que los contiene — los patrones que aparecen directamente en colas de mensajes, pipelines de procesamiento y motores de reglas de negocio. | Medio | Motor de precios con Strategy (descuento por volumen, temporada, usuario VIP); Order Saga con Command y compensaciones; sistema de alertas con Observer que notifica múltiples canales ante un evento de dominio. | PythonAgregar nueva estrategia de precio sin modificar el motor; Command soporta undo en tests; Observer desacoplado: publisher no conoce a sus subscribers; cada patrón con tests unitarios que documentan los contratos. | |
| Calidad de Código |
Clean Code: nombres, funciones pequeñas, comentarios y refactoring
Nombres que revelan intención · funciones de un solo nivel de abstracción · comentarios vs código auto-documentado · "Don't Repeat Yourself" vs "Wrong Abstraction" · Boy Scout Rule
|
Escribir código que comunique su propósito sin necesidad de explicación verbal — la condición previa para que un sistema pueda evolucionar sin que su complejidad crezca más rápido que su funcionalidad. | Fácil | Refactorizar un módulo de procesamiento de órdenes con 3 niveles de indentación, variables de un solo carácter y comentarios obsoletos. Pasar revisión de un compañero que nunca vio el módulo sin explicación previa. | PythonRevisión ciega aprobada sin preguntas de aclaración; funciones con máximo 2 niveles de indentación; 0 comentarios que explican "qué" (solo "por qué"); nombres auto-documentados verificados con Pylint sin warnings. | |
| Fundamentos de BD |
Modelado relacional: normalización, integridad referencial y decisiones de diseño
1NF/2NF/3NF/BCNF · desnormalización intencional · relaciones M:N · claves naturales vs surrogadas · constraints como documentación · evolución de esquema
Principios SOLID (el modelo de datos también debe ser mantenible)
|
Diseñar esquemas que sobrevivan el crecimiento del dominio con mínima deuda técnica — las decisiones de modelado de datos tomadas en el día 1 son las más difíciles de revertir en el día 1000. | Medio | Modelar el dominio de una plataforma de cursos online: usuarios, cursos, lecciones, inscripciones, progreso, certificados y pagos. Documentar cada decisión de normalización vs desnormalización con justificación explícita. | PythonEsquema en 3NF con justificación documentada; cada desnormalización con su "cuándo" y "por qué"; script Python con SQLAlchemy que genera datos de prueba realistas (10k usuarios, 500 cursos); 0 datos huérfanos posibles por constraints. | |
| HTTP y APIs |
HTTP semántico: métodos, status codes, headers y REST constraints
Idempotencia · safe methods · status codes correctos (201 vs 200, 422 vs 400) · content negotiation · HTTP caching headers · HATEOAS · Richardson Maturity Model
|
Diseñar APIs que usen HTTP como fue concebido — los clientes que las consuman podrán asumir comportamientos correctos sin consultar documentación de cada endpoint. | Fácil | Auditar una API existente de 20 endpoints: documentar cada violación semántica (DELETE que retorna 200, POST idempotente, 500 en validación) y proponer la corrección con justificación de la RFC correspondiente. | PythonScript Python con httpx que prueba idempotencia de todos los endpoints PUT/DELETE automáticamente; cada corrección referenciada a una RFC; checklist de auditoría reutilizable para futuros proyectos. |
|
| Fundamentos de Sistema |
Complejidad accidental vs esencial: el arte de elegir la solución más simple
KISS · YAGNI · "Make it work, make it right, make it fast" · over-engineering antipatterns · microservicios prematuros · el costo de las abstracciones prematuras · leer código de producción real
|
Desarrollar el instinto de cuándo la solución "más elegante" no es la más adecuada — la habilidad más difícil de enseñar y la que separa a los buenos arquitectos del resto. | Fácil | Analizar 3 case studies de over-engineering real (Segment migrando de microservicios a monolito, etc.) y escribir un reporte de 1 página por caso: qué decisión se tomó, qué problema creó y cuál habría sido la alternativa más simple. | Reporte con métricas concretas de costo del over-engineering; alternativa propuesta es demostrable como más simple; análisis validado en discusión con un mentor; conclusiones aplicadas al siguiente proyecto personal. |
02
| Área | Tema Específico | Objetivo | Dif. | Recursos | Proyecto / Validación | Criterio de Éxito |
|---|---|---|---|---|---|---|
| Arquitecturas en Capas |
Layered Architecture: Presentation, Business, Persistence y sus contratos
Separation of concerns · dependency rule (capas inner no conocen outer) · anemic domain model antipattern · service layer · DTO vs domain model · mappers
SOLID (DIP entre capas) + Patrones GoF (Factory, Facade entre capas)
|
Estructurar una aplicación para que los cambios en la capa de presentación no rompan la lógica de negocio, y los cambios de base de datos no rompan la capa de servicio — el principio de estabilidad que define la mantenibilidad a largo plazo. | Medio | API de e-commerce con 3 capas explícitas: controladores HTTP, servicios de dominio y repositorios de persistencia. Demostrar que el servicio de dominio tiene 0 imports de frameworks HTTP o SQL — testeable con mocks puros. | PythonCapa de dominio sin imports de FastAPI, SQLAlchemy ni httpx; tests del servicio usando repositorio in-memory; cambiar de SQLAlchemy a un repositorio mock no requiere modificar la capa de servicios; DTOs mapean explícitamente en los bordes. | |
| Diseño de API REST |
API Design: nomenclatura de recursos, versionado, paginación y error contracts
Resource naming conventions · versioning strategies (header vs URL vs param) · cursor vs offset pagination · RFC 9457 Problem Details · idempotency keys · rate limiting headers · OpenAPI 3.1
HTTP semántico (Trainee) + Layered Architecture (controllers son la capa de presentación)
|
Diseñar APIs que sean predecibles para sus consumidores y evolucionen sin breaking changes — el estándar de API design documentado en los engineering blogs de Stripe y Shopify. | Medio | API de marketplace con 15+ endpoints: versionado con header, cursor pagination en colecciones >1000 items, error responses con RFC 9457, idempotency key en POST /payments, OpenAPI 3.1 completo y auto-generado. |
Pythonv1 y v2 coexisten sin breaking change; cursor pagination sin inconsistencias bajo writes concurrentes; error response tiene type, title, detail; idempotency key previene doble cobro verificado en test concurrente. |
|
| Persistencia |
Estrategias de persistencia: SQL vs NoSQL vs NewSQL — cuándo y por qué
ACID vs BASE · teorema CAP básico · document DB (MongoDB) · key-value (Redis) · wide-column (Cassandra) · criterios de elección: consistencia, escala, flexibilidad de esquema, relaciones
Modelado relacional (Trainee) + Layered Architecture (Repository Pattern abstrae el motor)
|
Elegir el motor de persistencia adecuado para cada tipo de dato — una de las decisiones arquitectónicas más costosas de revertir, donde el error más común es usar PostgreSQL para todo o MongoDB para todo. | Medio | Diseñar la capa de persistencia de una plataforma social: PostgreSQL para perfiles y relaciones sociales, Redis para feed y sesiones, MongoDB para posts sin esquema fijo. Documentar cada decisión con criterios explícitos. | PythonCada motor elegido con al menos 3 criterios documentados; Repository Pattern abstrae los 3 motores con la misma interfaz Python; tests del dominio funcionan con repositorios in-memory independientemente del motor real. | |
| Caching |
Patrones de caché: Cache-Aside, Read-Through, Write-Through y TTL design
Cache invalidation strategies · stampede prevention (mutex lock) · warm-up · partial caching · cache hierarchy (local + distributed) · TTL por tipo de dato · cache miss rate monitoring
Persistencia (qué se cachea) + HTTP semántico (HTTP caching headers)
|
Reducir la latencia P95 de endpoints críticos en ≥60% sin introducir inconsistencias de datos — el balance entre rendimiento e integridad que define la calidad del diseño de caché. | Medio | Caching layer para una API de catálogo de productos: Cache-Aside para productos, TTL diferenciado (1h productos estables, 30s precios), stampede prevention con Lua script en Redis, invalidación por evento al actualizar un producto. | PythonLatencia P95 reducida ≥60% verificada con Locust; 0 stampede bajo 100 solicitudes simultáneas de cache miss; invalidación correcta verificada con test de consistencia; hit ratio >80% medido con métricas de Redis. | |
| Mensajería Básica |
Message Queues: RabbitMQ, patrones Producer/Consumer y at-least-once delivery
AMQP · exchanges y routing keys · Dead Letter Queue · message acknowledgment · idempotent consumers · retry con backoff · poison messages · ordering guarantees
Patrones Observer/Command (Trainee) + Persistencia (mensajes persisten en broker)
|
Desacoplar productores de consumidores para que los picos de carga no degraden la API y los fallos en consumidores no bloqueen el flujo principal — los fundamentos de cualquier arquitectura event-driven. | Medio | Pipeline de procesamiento de pedidos: API produce a RabbitMQ en <5ms; 3 consumidores idempotentes (email, inventario, analytics); DLQ procesa mensajes fallidos con backoff; 0 pedidos perdidos bajo 1000 mensajes concurrentes. | PythonAPI responde en <5ms sin esperar al consumidor; 0 mensajes perdidos en 1000 envíos incluyendo fallos simulados de consumidores; consumidor idempotente: procesar el mismo mensaje N veces produce el mismo resultado verificado en test. | |
| Testing Arquitectónico |
Pirámide de tests: unitarios, integración y contract testing con Pact
Unit vs integration vs E2E · test doubles: stub vs mock vs fake · in-memory repositories · Pact para contract testing · test data builders · mutation testing con mutmut
Layered Architecture (tests por capa) + Persistencia (repositorios in-memory)
|
Diseñar una estrategia de tests que valide la arquitectura además del comportamiento — tests que fallen cuando se viola un contrato entre capas, no solo cuando falla una funcionalidad. | Medio | Suite con 3 capas: 80% tests unitarios de dominio (sin DB), 15% integración con DB real en Docker, 5% Pact contract tests con el frontend. Mutation score >75% en la capa de dominio con mutmut. |
PythonTests unitarios corren en <2s sin Docker; Pact contract publicado y verificable; mutmut >75% en dominio; CI falla si un contract test falla; test data builders reutilizables entre capas de test. | |
| Observabilidad |
Observabilidad básica: logging estructurado, métricas de aplicación y tracing
Structured logging con correlation ID · métricas RED (Rate, Errors, Duration) · health check endpoints · readiness vs liveness · errores como eventos de negocio · alertas básicas de SLA
Layered Architecture (observabilidad en la capa de infraestructura) + HTTP (endpoints de health)
|
Instrumentar una aplicación para que el estado del sistema sea visible sin SSH al servidor — el primer paso hacia la operación autónoma que diferencia software de producción del software de demo. | Fácil | Instrumentación completa de la API: JSON logs con request_id, métricas RED expuestas via Prometheus, health endpoint con estado de DB y cola, alerta cuando latencia P99 >500ms, dashboard Grafana con las 4 Golden Signals. |
PythonDiagnosticar cualquier request fallido en <2 min solo con logs y traces; alerta dispara en escenario de prueba en <1 min; health endpoint diferencia "degraded" de "down"; sin print() en el código de producción. |
|
| Seguridad Básica |
Seguridad en el diseño: autenticación, autorización y OWASP Top 10 API
Authentication vs authorization · JWT vs sessions · RBAC vs ABAC · OWASP API Security Top 10 (2023) · Broken Object Level Authorization · Mass Assignment · Injection · rate limiting
API Design + Persistencia (queries parametrizadas contra inyección)
|
Diseñar seguridad desde el primer endpoint en lugar de añadirla después — las vulnerabilidades de autorización son la causa #1 de brechas en APIs según OWASP 2023, y son triviales de prevenir en el diseño. | Medio | API con RBAC: usuarios solo acceden a sus propios recursos (BOLA corregido), mass assignment prevenido en todos los endpoints, inputs validados con Pydantic, rate limiting por API key, auditoría de acceso a datos sensibles. | PythonChecklist OWASP API Top 10 pasado con 0 vulnerabilidades críticas; BOLA verificado con test de usuario A accediendo a recursos de usuario B; Semgrep sin hallazgos de inyección; rate limiting funcional bajo test de carga. |
03
| Área | Tema Específico | Objetivo | Dif. | Recursos | Proyecto / Validación | Criterio de Éxito |
|---|---|---|---|---|---|---|
| DDD Táctico |
Domain-Driven Design: Entities, Value Objects, Aggregates y Domain Events
Entity vs Value Object · Aggregate Root · invariant enforcement · Domain Events · Domain Services · Anemic vs Rich Domain Model · ubiquitous language · bounded context intro
SOLID + Patrones GoF + Layered Architecture
|
Modelar la lógica de negocio en el código de forma que un experto del dominio pueda leer el modelo y reconocerlo — la práctica que diferencia software que sobrevive 10 años del que se reescribe en 2. | Difícil | Dominio de e-commerce con DDD táctico: Order como Aggregate Root que protege sus invariantes (no se puede agregar item a orden confirmada), Money como Value Object, Domain Events al confirmar pago. 0 setters públicos en entidades. |
PythonInvariantes del dominio imposibles de violar desde fuera del Aggregate; Value Objects inmutables y comparables por valor; Domain Events recolectados en el Aggregate y despachados post-persistencia; 0 lógica de negocio fuera del dominio. | |
| DDD Estratégico |
Bounded Contexts, Context Maps y Strategic Design
Bounded Context · ubiquitous language por contexto · Context Map (Shared Kernel, Customer/Supplier, ACL) · Anti-Corruption Layer · subdomain types: core, supporting, generic
DDD Táctico + API Design (contratos entre contextos)
|
Dividir un sistema complejo en contextos con modelos independientes que eviten el acoplamiento semántico — la práctica que Uber, Shopify y Netflix aplican para escalar equipos sin escalar la complejidad. | Difícil | Context Map de una plataforma de logística: Ordering, Shipping, Billing, Notifications y Inventory como Bounded Contexts separados; ACL entre Ordering y el BC externo de courier; traducción explícita de Order en cada contexto. |
PythonCada BC con su propio ubiquitous language documentado; ACL traduce el modelo externo sin contaminar el dominio propio; cambio en el modelo de Shipping no requiere cambios en Ordering; diagrama de Context Map aprobado en revisión técnica. | |
| Arquitectura Hexagonal |
Ports & Adapters (Hexagonal): core aislado, puertos y adaptadores
Driving vs driven adapters · Port como interfaz Python (
Protocol) · Adapter concreto (SQLAlchemy, httpx, Redis) · Application Services · dependency inversion completa · testabilidad totalDDD Táctico + SOLID DIP + Layered Architecture (evolución natural)
|
Aislar el núcleo de negocio de toda infraestructura externa para que el dominio sea testeado sin DB, sin HTTP y sin colas — el modelo adoptado por Shopify y Stripe para sistemas de core business críticos. | Difícil | Reescribir el módulo de pagos del proyecto Junior en Hexagonal: PaymentPort como Protocol, adaptadores para Stripe y PayPal, Application Service orquestador, tests de dominio sin ningún import externo. |
PythonTests de dominio corren en <500ms sin DB ni HTTP; cambiar de Stripe a PayPal requiere solo un nuevo Adapter; Application Service tiene 0 imports de frameworks; capa de dominio sin dependencias externas verificada con import-linter. |
|
| Microservicios |
Microservicios vs Monolito: trade-offs, patrones de descomposición y service mesh
Decomposition by subdomain/capability · Strangler Fig pattern · API Gateway · service discovery · distributed tracing · network fallacies · fallacies of distributed computing · cuando NO usar microservicios
DDD Estratégico (Bounded Context → servicio candidato) + Mensajería + Observabilidad
|
Razonar sobre el trade-off más sobrediscutido de la arquitectura moderna con criterios objetivos — incluyendo los casos donde un monolito bien estructurado supera a los microservicios en rendimiento, operabilidad y velocidad de desarrollo. | Difícil | ADR que documenta la decisión de dividir un monolito en microservicios para una startup: criterios de descomposición, análisis de costos operacionales, plan de migración con Strangler Fig y métricas de éxito para evaluar la migración. | PythonADR incluye el escenario donde NO conviene migrar; script Python analiza el grafo de dependencias del monolito para identificar candidatos naturales de extracción; criterios de decisión validados con case study real (Segment, Shopify o similar). | |
| Event-Driven |
Kafka: topics, partitions, consumer groups y garantías de entrega
Log-based messaging · at-least-once vs exactly-once · consumer groups · offset management · schema registry con Avro/Protobuf · compaction · Kafka Streams básico · CDC con Debezium
Mensajería básica (RabbitMQ conceptos) + DDD (Domain Events como mensajes Kafka)
|
Implementar mensajería de alta throughput con garantías de durabilidad y orden — la columna vertebral de la arquitectura event-driven que Uber, Netflix y MercadoLibre usan para billones de eventos diarios. | Difícil | Pipeline de eventos de usuario: producer en FastAPI publica eventos de negocio, consumer group de analytics con Schema Registry (Avro), CDC con Debezium para sincronizar 2 servicios, reprocessing de eventos históricos desde offset 0. | Python0 mensajes perdidos en 100k eventos incluyendo reinicios del broker; Schema Registry rechaza schemas incompatibles; reprocessing desde offset 0 produce el mismo estado final; consumer lag monitoreado en Grafana con alerta si >10k mensajes. | |
| Distributed Systems |
CAP Theorem, consistencia eventual y patrones Saga y Outbox
CAP · PACELC · consistency models (strong, eventual, causal) · Saga: choreography vs orchestration · Transactional Outbox Pattern · idempotency · compensating transactions · Two-Phase Commit problemas
Kafka (mensajería de Sagas) + Persistencia (Outbox en DB) + DDD Táctico (Aggregates + transacciones)
|
Gestionar la consistencia de datos entre servicios sin transacciones distribuidas — el problema más común y menos bien resuelto en arquitecturas microservicios, con patrones que usan Netflix, Uber y Stripe. | Difícil | Saga de creación de pedido: Outbox Pattern garantiza que el evento se publica si y solo si el registro persiste; compensaciones correctas si el servicio de stock falla después de creada la orden; sin 2PC en ningún punto. | Python0 órdenes en estado inconsistente tras 1000 sagas incluyendo fallos simulados en cada paso; compensación ejecutada correctamente en los 5 puntos de fallo posibles; script Python de chaos test inyecta fallos y verifica consistencia final. | |
| Performance |
Database performance: índices avanzados, EXPLAIN ANALYZE y query optimization
Índices parciales · covering indexes · índices compuestos y orden de columnas ·
pg_stat_statements · query planning · N+1 detection · connection pooling (PgBouncer) · read replicasModelado relacional + Caching (performance complementaria) + Observabilidad
|
Optimizar la capa de base de datos con evidencia cuantitativa antes de proponer cambios arquitectónicos — la regla de oro: medir antes de escalar horizontalmente. | Difícil | Reducir la query más lenta de una API de analytics de 4s a <200ms; documentar cada índice creado con EXPLAIN ANALYZE antes/después; 0 Seq Scans en tablas >100k filas; PgBouncer configurado con pool sizing correcto para la carga real. | PythonEXPLAIN ANALYZE evidencia mejora ≥10x; script Python usa pg_stat_statements para identificar el próximo query costoso automáticamente; PgBouncer elimina overhead de conexiones verificado con pgbench; mejora mantenida bajo carga de 30 días. |
|
| Resiliencia |
Patrones de resiliencia: Circuit Breaker, Retry, Bulkhead y Timeout
Circuit Breaker states (closed/open/half-open) · exponential backoff + jitter · Bulkhead para aislar fallos · timeout cascading · fallback strategies · health check endpoints · fail fast vs fail safe
HTTP Async + Distributed Systems (contexto de por qué son necesarios)
|
Diseñar servicios que degraden con gracia ante fallos de sus dependencias sin propagarlos en cascada — la característica que separa un servicio de producción de uno que derriba todo el sistema cuando falla una dependencia no crítica. | Difícil | Client de servicio de recomendaciones con Circuit Breaker (abre en 5 fallos/30s), retry con backoff exponencial + jitter, Bulkhead de 10 conexiones concurrentes máximo, fallback a recomendaciones populares cuando el circuito está abierto. | PythonServicio de recomendaciones caído no degrada latencia de la API principal más de 50ms; Circuit Breaker abre en <5s y prueba recuperación automáticamente; Bulkhead previene que 1 consumidor lento bloquee al resto; tests de chaos verifican cada estado. |
04
| Área | Tema Específico | Objetivo | Dif. | Recursos | Proyecto / Validación | Criterio de Éxito |
|---|---|---|---|---|---|---|
| CQRS & Event Sourcing |
CQRS: separación de modelos de lectura/escritura y proyecciones
Command vs Query sides · read models como proyecciones · eventual consistency en las vistas · separate datastores · synchronous vs async projections · snapshots · cuándo NO usar CQRS
DDD Táctico + Kafka (proyecciones async) + Patrones de persistencia
|
Separar el modelo de escritura (transaccional, consistente, complejo) del modelo de lectura (desnormalizado, fast, flexible) para que cada uno pueda escalar y evolucionar de forma independiente — patrón central en Airbnb y Stripe. | Experto | CQRS para un sistema bancario: write side en PostgreSQL con DDD Aggregates, read side en Elasticsearch proyectado via Kafka; latencia de lectura <20ms vs <200ms en write; reconstrucción de read model desde 0 sin downtime. | PythonLectura P99 <20ms con Elasticsearch; reconstrucción del read model en <10 min desde cero; ADR que documenta por qué CQRS aplica aquí y en qué casos NO aplicaría; script Python de proyección re-runnable e idempotente. | |
| Event Sourcing |
Event Sourcing: event store, snapshots, projections y temporal queries
Append-only event log · event replay · snapshots para performance · aggregate reconstitution · temporal queries ("estado en el tiempo T") · upcasting de eventos · event versioning · correlación de eventos
CQRS + DDD Táctico (Domain Events como eventos de sourcing) + Kafka
|
Diseñar sistemas donde el estado es derivado de una secuencia inmutable de eventos — el modelo que permite auditoría completa, replay para debugging y reconstrucción del pasado que Stripe y Amazon usan en sus sistemas de pagos. | Experto | Event Store para dominio de cuenta corriente: cada transacción como evento inmutable, reconstrucción del saldo desde cualquier punto temporal, snapshot cada 100 eventos, query del saldo al 01/01/2025 a las 09:00 exacto. | PythonSaldo reconstruido desde eventos == saldo actual en 10k cuentas de test; temporal query en <100ms con snapshots; eventos no modificables verificado por hash; upcasting de eventos v1 a v2 sin reescribir el event log. | |
| Escala y Disponibilidad |
Sharding, replicación y arquitectura multi-región con failover automático
Horizontal sharding strategies (range, hash, directory) · rebalancing · read replicas · lag monitoring · multi-AZ vs multi-region · active-active vs active-passive · RTO/RPO · Global Tables (DynamoDB) · CockroachDB
Database performance + CAP Theorem + Distributed Systems
|
Diseñar la capa de datos para que sobreviva la caída de una región completa con RTO <1 min — el estándar de disponibilidad de Netflix, Amazon y Stripe que se mide en segundos de downtime por año. | Experto | Arquitectura de DB multi-región: RDS Multi-AZ en primary region + read replica en secondary; failover automático probado con aws rds failover-db-cluster; RTO <60s verificado; script de monitoreo de replica lag con alerta si >5s. |
PythonRTO medido <60s en failover simulado; 0 transacciones perdidas (RPO=0) verificado; script Python monitorea replica lag y activa read-only mode automáticamente si lag >5s; arquitectura documentada con diagramas de fallos y recuperación. | |
| API a Escala |
API Gateway, BFF, GraphQL Federation y gestión de versiones a escala
API Gateway patterns · Backend for Frontend (BFF) · GraphQL Federation (Apollo) · schema stitching · API versioning lifecycle · deprecation policies · consumer-driven contracts · traffic shaping
API Design + Microservicios + Contract Testing
|
Diseñar la capa de entrada de un ecosistema de microservicios que sirva a múltiples clientes (web, mobile, partners) con contratos independientes y sin acoplamiento entre consumidores y servicios downstream. | Experto | API Gateway con 3 BFFs (web/mobile/partners); GraphQL Federation que compone schemas de 4 microservicios; política de deprecación con sunset headers; traffic shaping que dirige el 10% del tráfico de mobile a la nueva versión del BFF. | PythonBFF mobile reduce payload en ≥50% vs API genérica; Federation resuelve queries cross-service en <100ms; versión antigua recibe sunset header con fecha; traffic shaping sin downtime verificado con Locust; script Python valida compatibilidad de schemas en CI. | |
| Seguridad Avanzada |
Zero Trust Architecture, mTLS entre servicios y threat modeling
Zero Trust principles · mTLS para comunicación inter-servicio · SPIFFE/SPIRE para identidad de workload · STRIDE threat modeling · Data Flow Diagrams · attack surface reduction · secrets rotation · penetration testing basics
Seguridad básica + Microservicios (superficie de ataque distribuida) + Observabilidad (audit logs)
|
Diseñar sistemas donde ninguna comunicación interna se asume segura por defecto — el modelo de seguridad adoptado por Google (BeyondCorp), Netflix y Stripe que reduce drásticamente el radio de explosión de una brecha. | Experto | Threat model STRIDE del sistema de pagos: DFD de 3 niveles, 10+ amenazas identificadas y mitigadas, mTLS entre todos los microservicios del core, rotación automática de secretos, audit log de cada acceso a datos de tarjeta. | PythonSTRIDE completo con mitigación documentada; mTLS verificado en 100% del tráfico inter-servicio via Kiali; secretos con TTL máx 24h; script Python verifica que 0 certificados expirados en producción y alerta 7 días antes de expiración. | |
| System Design |
System Design a escala: diseñar sistemas que soporten 10M+ usuarios
Back-of-the-envelope estimation · bottleneck identification · horizontal vs vertical scaling · CDN integration · read/write ratio analysis · SLA/SLO definitions · capacity planning · designing Twitter, Uber, Netflix-scale
Todo el nivel SSR + CQRS + Sharding + Caching
|
Diseñar sistemas a escala partiendo de requisitos de negocio ambiguos — la habilidad central de las entrevistas de Staff/Principal Engineer y la competencia más valorada en las empresas más grandes del mundo. | Experto | Diseño completo de 3 sistemas a escala: URL shortener (10B clicks/día), feed de redes sociales (100M DAU) y sistema de pagos en tiempo real (1M TPS). Cada uno con estimaciones, componentes, base de datos elegida y justificación de trade-offs. | PythonEstimaciones back-of-the-envelope documentadas y verificables; cada componente justificado con trade-offs explícitos; diseño presentado en 45 min y aprobado en simulación de entrevista; script Python simula la carga para validar el diseño. | |
| Observabilidad Avanzada |
Observabilidad de sistemas distribuidos: SLOs, error budgets y chaos engineering
SLI/SLO/SLA distinción · error budget policies · burn rate alerts · chaos engineering (LitmusChaos) · Game Days · dependency mapping · synthetic monitoring · distributed tracing cross-service
Observabilidad básica + Resiliencia + Distributed Systems
|
Medir la fiabilidad de sistemas complejos con métricas que reflejan la experiencia real del usuario y probar activamente la capacidad del sistema de recuperarse de fallos — la práctica que diferencia los sistemas que "están bien" de los que demuestran que están bien. | Difícil | SLO de 99.95% de disponibilidad con error budget policy documentada; Game Day con 5 escenarios de fallo (DB down, Kafka lag, dependencia externa caída, pod kill masivo); sistema sobrevive todos los escenarios con degradación graceful. | PythonError budget nunca consumido más del 90% en 3 meses; Game Day documentado con timeline, impacto y action items; script Python de chaos inyecta latencia a servicios dependientes y verifica que el Circuit Breaker actúa en <5s. | |
| Liderazgo Técnico |
Architecture Decision Records (ADR), RFCs y technical design reviews
ADR format (context/decision/consequences/status) · RFC process · design review facilitation · architecture fitness functions · ArchUnit equivalents · technical debt ledger · decision reversibility
Toda la experiencia Senior acumulada como fuente de las decisiones a documentar
|
Documentar las decisiones arquitectónicas más importantes con su contexto, alternativas y consecuencias para que el equipo las entienda sin explicación verbal y las pueda revaluar en el futuro con el mismo contexto. | Medio | 5 ADRs para decisiones reales del sistema: elección de event store, estrategia de versionado de API, separación de bounded contexts, política de cache invalidation y adopción de GraphQL. Fitness functions automáticas que validan las decisiones en CI. | PythonADRs con alternativas rechazadas y su justificación; fitness functions en Python corren en CI y fallan si una decisión se viola (ej: import entre BCs incorrectos); aprobados por el equipo en ≤2 iteraciones; referenciados en code reviews. |
05
| Área | Tema Específico | Objetivo | Dif. | Recursos | Proyecto / Validación | Criterio de Éxito |
|---|---|---|---|---|---|---|
| Arquitectura de Referencia |
Golden Path Architecture: modelo de referencia, paved roads y fitness functions
Architecture as product · golden path templates · paved roads · fitness functions automatizadas · ArchUnit Python equivalents · architecture governance sin burocracia · architecture as code · tech radar
ADRs + DDD Estratégico + toda la plataforma de niveles anteriores
|
Diseñar el camino de menor resistencia para que los equipos hagan lo correcto por defecto — la diferencia entre un arquitecto que aprueba diseños y uno que hace innecesario pedir aprobación porque el camino correcto ya está pavimentado. | Experto | Golden Path para nuevos microservicios: template que incluye Hexagonal Architecture, Kafka consumers idempotentes, OpenTelemetry, RBAC, CQRS cuando aplica; fitness functions en Python que se ejecutan en CI de todos los servicios y reportan desviaciones. | PythonFitness functions detectan automáticamente violaciones del modelo de referencia (import de DB en capa de dominio, Controller sin Pydantic, etc.); adopción >80% del equipo de ingeniería; nuevo servicio que sigue el Golden Path tiene 0 findings en review. | |
| IA Nativa |
AI-native Backend: RAG, agentes, MCP y arquitectura de sistemas con LLMs
RAG architecture · vector stores (pgvector, Qdrant) · LLM orchestration (LangGraph, PydanticAI) · Model Context Protocol (MCP) · tool calling · semantic caching · latency vs accuracy trade-off · LLMOps
Event Sourcing (estado para agentes) + CQRS (read models para RAG) + Kafka (eventos de agentes)
|
Diseñar sistemas donde la IA es una capacidad de primera clase en la arquitectura backend, no un añadido — el patrón arquitectónico central de los backends más competitivos en 2026 según Google, Stripe y Anthropic. | Experto | Backend de soporte con agente LangGraph que accede a DBs de clientes via MCP, RAG sobre documentación técnica (pgvector, precision@10 >85%), semantic cache que reduce llamadas a LLM en ≥60%, trazas de agente en OpenTelemetry. | PythonResolución autónoma >70% de queries; RAG faithfulness >0.85 en RAGAS; semantic cache hit ratio >60%; latencia P95 <3s; traza completa del agente observable en Jaeger; tests con TestModel sin llamadas reales al LLM. | |
| IA Nativa |
LLMOps: evaluación continua, detección de drift y governance de modelos
Evaluation pipelines (RAGAS, UpTrain) · A/B testing de modelos · hallucination detection · prompt versioning · model fallback strategies · cost attribution por feature · privacy en prompts · PII detection
IA Nativa (sistemas LLM en producción) + Observabilidad avanzada + CI/CD
|
Operar sistemas LLM en producción con la misma rigurosidad que los sistemas tradicionales — evaluar calidad de respuestas continuamente, detectar degradación y garantizar que los datos de usuarios no se filtran a los modelos. | Experto | Pipeline de evaluación en CI que corre RAGAS sobre dataset de 200 preguntas en cada deploy; alerta si faithfulness cae >5%; PII detector que sanitiza prompts antes de enviar al LLM; A/B test entre GPT-4o y Claude con métricas de negocio. | PythonDeploy bloqueado si RAGAS baja más del 5%; 0 PII filtrado al LLM verificado con test adversarial; A/B test con significancia estadística p<0.05; costo por feature atribuido correctamente en el dashboard de FinOps. | |
| Platform Engineering |
Backend Platform: SDK interno, abstracciones de dominio y developer experience
Internal SDK design · API ergonomics · platform NPS · golden paths para patrones recurrentes (Saga, Outbox, CQRS) · migration tooling · deprecation lifecycle · contribution model · dogfooding
Golden Path Architecture + DDD Estratégico + IA Nativa (capacidades del SDK)
|
Crear abstracciones que hagan trivial para cualquier equipo implementar correctamente los patrones más complejos (Saga, Outbox, CQRS) — el multiplicador de fuerza que convierte al Staff Architect en el catalizador de 20 equipos. | Experto | SDK interno Python con: @saga decorator que implementa Transactional Outbox automáticamente, CqrsAggregate base class para CQRS sin boilerplate, DomainEvent con Kafka publishing automático; adoptado por >5 equipos con NPS >40. |
PythonImplementar una Saga correcta con el SDK requiere <50 líneas vs >500 manualmente; NPS interno >40; 0 bugs de Outbox/duplicados en servicios que usan el SDK; contribution guide permite que un equipo externo envíe su primer PR en <1 día. | |
| DORA Metrics |
DORA Metrics, Developer Experience y eliminación de toil arquitectónico
Deployment Frequency · Lead Time for Changes · MTTR · Change Failure Rate · SPACE framework · architectural toil (coupling que frena el delivery) · feedback loops · dashboards automatizados
Architecture as Code (fitness functions como datos para DORA) + Platform Engineering
|
Medir el impacto de las decisiones arquitectónicas en la velocidad de entrega del equipo con datos objetivos — el Staff Architect que mejora el DORA score de "Medium" a "Elite" tiene más impacto que cualquier optimización de un sistema individual. | Experto | Dashboard DORA automatizado desde GitHub + PagerDuty; identificar el bottleneck arquitectónico que más impacta el Lead Time (ej: acoplamiento entre servicios aumenta tiempo de testing); plan de amortización con impacto estimado en cada métrica. | PythonScript Python ingesta GitHub API y PagerDuty; equipo en tier "High" en ≥3 de 4 métricas DORA en 6 meses; cada iniciativa arquitectónica con métrica de impacto en DORA documentada; toil de arquitectura reducido en ≥30%. | |
| Estrategia Técnica |
Roadmap de arquitectura: OKR alignment, build vs buy y tech debt a escala
Technical strategy document · build vs buy framework · RFC process · OKR alineación con arquitectura · tech debt ledger (architectural debt) · migration planning · stakeholder communication · hiring technical
DORA Metrics + ADRs + Platform Engineering (iniciativas del roadmap)
|
Traducir la visión técnica en un roadmap ejecutable alineado con los objetivos del negocio — la competencia que distingue al Staff Architect del Senior: no solo sabe qué hay que hacer, sino cómo convencer a la organización y ejecutarlo. | Experto | Documento de estrategia técnica de 18 meses: migración de monolito legacy a arquitectura hexagonal + event-driven, plataforma AI-native, OKRs por iniciativa con métricas de negocio; aprobado por CTO con tracking trimestral. | Aprobado en revisión con VPs en primera iteración; cada iniciativa con OKR y métrica de negocio (no solo técnica); roadmap comunicado al equipo de ingeniería y comprendido sin reunión adicional; 3 iniciativas prioritarias iniciadas en el primer trimestre. | |
| Multi-Cloud & FinOps |
Arquitectura cloud-agnostic: portabilidad, FinOps y decisiones de build vs vendor
Abstraction layers sobre cloud providers · vendor lock-in risk model · cost modeling por arquitectura · rightsizing a nivel de diseño · serverless vs containers trade-offs · FinOps maturity · cost-aware architecture
Multi-región + Platform Engineering + Estrategia técnica
|
Tomar decisiones de arquitectura con plena consciencia de su costo operacional a largo plazo — el arquitecto que entiende FinOps diseña sistemas que escalan sin que el costo crezca linealmente con el tráfico. | Experto | Modelo de costo para 3 alternativas arquitectónicas (microservicios en K8s, serverless, monolito modular) a 100k, 1M y 10M usuarios; decisión documentada con costo proyectado; plan de rightsizing que reduce bill en >20% sin degradar SLOs. | PythonModelo de costo en Python con parámetros ajustables para distintos escenarios de crecimiento; reducción >20% documentada; alternativa elegida justified con métricas de costo + operabilidad + velocidad de desarrollo; revisada con el equipo de finanzas. | |
| Open Source & Comunidad |
Thought leadership, open source y mentoring en arquitectura
Contribuciones a proyectos de arquitectura (FastAPI, SQLAlchemy, Pydantic) · QCon/InfoQ talks · engineering blog · mentoring de SSR a Senior · RFC públicas · Architecture Guild facilitación · escritura técnica de impacto
Todo el nivel Staff — impacto acumulado que se amplifica externamente
|
Amplificar el impacto más allá de la organización construyendo reputación en la comunidad de arquitectura de software que atrae talento senior, genera credibilidad institucional y retroalimenta con inteligencia del ecosistema. | Experto | Contribución aceptada a proyecto Python de arquitectura con >5k stars; charla en QCon, InfoQ o PyCon sobre arquitectura; post técnico con >1000 lecturas en Engineering Blog; 2 ingenieros SSR mentorados al nivel Senior en <12 meses. | PythonPR mergeada en repo con >5k stars; charla aceptada por CFP con revisión ciega; mentorado promovido o alcanza objetivo técnico acordado; post citado en al menos 3 otros artículos técnicos; Architecture Guild activa con contribuciones de >5 equipos distintos. |