Cada decisión técnica tiene contexto, costo y criterios. Cuando alguien pregunta '¿Cuál debo usar?', este catálogo ofrece una comparación para decidir.
"Hacer algo como siempre se ha hecho no significa que sea lo correcto ni lo mejor."
Cesar Zanis
Cuándo usar
Se necesita una respuesta inmediata. CRUD sencillo. Volumen bajo o medio. APIs públicas consumidas por navegadores.
Cuándo NO usar
Operaciones largas (>2 s). Distribución a varios consumidores. Consistencia eventual aceptable.
Costo del Trade-off
Acoplamiento temporal: un fallo del destino afecta al llamador.
Cuándo usar
Operaciones largas. Equipos independientes. Reintentos automáticos. Absorción de picos de tráfico.
Cuándo NO usar
El llamador necesita una respuesta inmediata, como en login, validación o checkout.
Costo del Trade-off
Complejidad inicial adicional: mensajes fallidos, supervisión de colas e idempotencia. El beneficio es una mayor resiliencia.
Cuándo usar
Comunicación interna frecuente entre servicios. Contratos fuertemente tipados. Streaming bidireccional.
Cuándo NO usar
APIs públicas para navegadores que necesitan soporte nativo. Equipos sin experiencia en protobuf.
Costo del Trade-off
Curva de aprendizaje y gestión de esquemas a cambio de contratos binarios eficientes y menor sobrecarga.
Cuándo usar
Endpoints frecuentes. JOIN complejos. Requisitos estrictos de latencia. Control del plan de ejecución.
Cuándo NO usar
CRUD administrativo sencillo. Prototipos donde importa más la velocidad de desarrollo.
Costo del Trade-off
Más código manual de mapeo a cambio de consultas explícitas y un comportamiento SQL más predecible.
Cuándo usar
CRUD de backoffice de bajo volumen. Prototipos. Equipos con experiencia limitada en SQL.
Cuándo NO usar
Sincronización móvil, informes pesados o endpoints con latencia estricta, salvo que se validen las consultas generadas.
Costo del Trade-off
Comodidad, con riesgo de consultas generadas ineficientes bajo carga real.
Cuándo usar
Tablas transaccionales, APIs públicas y necesidad de separar identificadores internos de los públicos.
Cuándo NO usar
Tablas pequeñas de referencia donde no hace falta otro identificador público.
Costo del Trade-off
Una columna adicional y un índice UNIQUE. Los identificadores públicos siguen necesitando controles de autorización.
Cuándo usar
Generación distribuida de identificadores. UUID v7 ordenados por tiempo. Identificadores generados en el cliente.
Cuándo NO usar
UUID aleatorios en índices agrupados con muchas escrituras sin medir la fragmentación y el almacenamiento.
Costo del Trade-off
Una columna identificadora. Evalúa tamaño del índice, localidad y almacenamiento del motor.
Cuándo usar
Historial de negocio, eliminación reversible y auditoría, sujetos a una política de retención definida.
Cuándo NO usar
Datos temporales sin necesidad de historial o datos que deben eliminarse de forma efectiva.
Costo del Trade-off
Una columna adicional y un filtro obligatorio en las lecturas pertinentes. La retención y la eliminación requieren gestión explícita.
Cuándo usar
Sesiones, tokens, contadores en tiempo real y datos compartidos. Define TTL, límites de memoria y políticas de expulsión.
Cuándo NO usar
Archivos binarios grandes o datos que conviene servir desde almacenamiento de objetos o una CDN. Evalúa tamaño y frecuencia de acceso.
Costo del Trade-off
Costos de memoria y operación. Comprueba que el beneficio de latencia los justifique.
Cuándo usar
Recursos estáticos. Respuestas de API inmutables y versionadas. Imágenes. Páginas sin personalización.
Cuándo NO usar
Datos específicos de usuario o en tiempo real sin una estrategia adecuada de caché privada o invalidación.
Costo del Trade-off
Generalmente económico. El reto principal es la invalidación: usa ETags o URLs versionadas.
Cuándo usar
Los datos cambian en cada solicitud, la inconsistencia resulta costosa o las consultas ya son suficientemente rápidas.
Cuándo NO usar
Consultas costosas que devuelven el mismo resultado durante varios minutos.
Costo del Trade-off
Menos complejidad de caché a cambio de carga en la base de datos y latencia.
Cuándo usar
Sistemas pequeños con pocas dependencias, dominio bien entendido y costos de migración documentados.
Cuándo NO usar
Sistemas en producción con muchos consumidores, reglas sin documentar o dominio poco conocido.
Costo del Trade-off
Alto riesgo de perder reglas de negocio implícitas. Requiere una decisión explícita y documentada.
Cuándo usar
Sistemas activos en producción, migración incremental con rollback y equipos que deben seguir entregando.
Cuándo NO usar
Sistemas triviales sin consumidores donde el mecanismo de migración aporta poco valor.
Costo del Trade-off
Más infraestructura y coordinación de migración. Puede reducir las interrupciones, pero no elimina el riesgo de caída.
Cuándo usar
Frameworks con soporte, equipos productivos y costos de migración superiores al beneficio claro.
Cuándo NO usar
Frameworks sin soporte, baja productividad y deuda técnica que crece más rápido que las entregas.
Costo del Trade-off
Menor costo inmediato. Requiere revisiones periódicas para que la deuda no se acumule sin detectarse.
Cuándo usar
Boilerplate, CRUD, pruebas y código que sigue un patrón establecido en el proyecto.
Cuándo NO usar
Algoritmos críticos de negocio que nadie en el equipo puede revisar con confianza.
Costo del Trade-off
Posibles mejoras en la entrega si se revisa y prueba el resultado. El código sin revisar introduce riesgos en producción.
Cuándo usar
Explorar alternativas, redactar borradores de ADR, analizar trade-offs y revisar propuestas.
Cuándo NO usar
Delegar la decisión final. La IA propone; las personas siguen siendo responsables.
Costo del Trade-off
Más perspectivas, limitadas por el contexto organizativo e histórico que proporcionas.
Cuándo usar
Código sensible, registros o datos personales que deben permanecer en infraestructura autorizada, con controles locales adecuados.
Cuándo NO usar
Tareas fuera de la capacidad del modelo local. Evalúa un servicio cloud permitido si cumple la política de datos.
Costo del Trade-off
El control local no garantiza seguridad. Considera acceso, telemetría, actualizaciones, hardware y calidad del modelo.
Si no puedes explicar cuándo NO usar un enfoque, todavía no entiendes sus trade-offs. Comprender el costo forma parte de la decisión.
Czanix Tech Reference¿Necesitas ayuda para evaluar un trade-off en tu contexto?
Hablar con Cesar Zanis
