Selección de Tecnología (Stack)
Nivel intermedio — criterios objetivos para elegir bases de datos, lenguajes y frameworks, evitando decisiones basadas en hype.
El problema
Situación típica: el equipo elige MongoDB porque "escala mejor". Seis meses después: el 90% de las queries son JOINs que MongoDB no maneja bien, nadie sabe modelar relaciones en documentos, y están considerando migrar a PostgreSQL perdiendo meses de trabajo. // la tecnología no encajaba con el patrón de acceso real
Elegir base de datos
Paso 1 — identifica el patrón de acceso: CRUD simple, consultas complejas (JOINs/agregaciones), búsqueda full-text, relaciones complejas (grafos), time-series, documentos jerárquicos, o key-value de alta velocidad.
| Categoría | Fortaleza | Debilidad | Ejemplos |
|---|---|---|---|
| SQL/Relacional | Consultas complejas, ACID | Escala de escritura, esquema rígido | PostgreSQL, MySQL |
| Documental | Esquema flexible | JOINs, transacciones multi-doc | MongoDB, CouchDB |
| Key-Value | Velocidad extrema | Sin queries complejas | Redis, DynamoDB |
| Columnar | Analytics sobre grandes volúmenes | Escrituras lentas, OLTP | ClickHouse, Cassandra |
| Grafos | Relaciones y traversals | Volumen de datos, queries simples | Neo4j, Neptune |
Paso 2 — aplica el Teorema CAP para sistemas distribuidos: solo puedes garantizar 2 de 3 propiedades (Consistency, Availability, Partition Tolerance). Las particiones de red ocurrirán, así que la elección real es entre CP (consistencia) y AP (disponibilidad) cuando hay partición.
| Si necesitas... | Elige | Ejemplos |
|---|---|---|
| Consistencia fuerte (finanzas, inventario) | CP | PostgreSQL + réplicas síncronas, MongoDB |
| Disponibilidad máxima (social media, contenido) | AP | Cassandra, DynamoDB, CouchDB |
| Ambos (ACID + escala) | NewSQL | CockroachDB, TiDB, Spanner |
Elegir lenguaje y framework
Criterio 1 — ¿qué conoce el equipo? La productividad de un equipo experto en una tecnología "subóptima" supera a un equipo novato en la tecnología "perfecta" — la curva de aprendizaje se paga en los primeros 6 meses. Regla: si el equipo tiene 2+ años de experiencia en una tecnología, necesitas razones muy fuertes para cambiar.
Criterio 2 — ¿qué necesita el problema?
| Tipo de problema | Lenguajes/frameworks típicos |
|---|---|
| API REST/GraphQL | Node.js, Python, Go, Java |
| UI Web | React, Vue, Angular, Svelte |
| Mobile cross-platform | React Native, Flutter |
| Data/ML | Python (TensorFlow, PyTorch) |
| Sistemas de alto rendimiento | Go, Rust, C++ |
| Enterprise con integraciones complejas | Java, .NET |
Criterio 3 — ¿cómo está el ecosistema? Librerías maduras para tus integraciones, actividad de comunidad, documentación oficial, disponibilidad de talento en tu mercado, riesgo de abandono del proyecto, y calidad del tooling (IDE, debugger, testing).
Framework de decisión: ADR tecnológico
- Contexto — ¿qué problema resuelve esta elección?
- Opciones — ¿qué alternativas consideramos?
- Criterios — ¿cómo evaluamos? (peso por criterio)
- Análisis — ¿cómo puntúa cada opción?
- Decisión — ¿qué elegimos y por qué?
- Consecuencias — ¿qué trade-offs aceptamos?
Es tentador tratar la elección de stack como un problema puramente técnico — comparar benchmarks, features, throughput. Pero el propio Criterio 1 dice que la familiaridad del equipo puede superar a la tecnología "objetivamente mejor" durante meses. Ignorar esto es el mismo error que MongoDB "porque escala mejor": optimizar una variable e ignorar el resto del sistema.
Practica: sistema de tickets de soporte
Selecciona el stack tecnológico (base de datos + lenguaje/framework) para un sistema de gestión de tickets de soporte técnico. Aplica los criterios de esta lección y documenta la decisión en formato ADR de 6 pasos.