11 publicaciones etiquetados con "Arquitectura de Software"

El 7 de mayo de 2026, miles de estudiantes en Estados Unidos, Reino Unido, Australia, Países Bajos y Suecia entraron a Canvas en plena semana de exámenes y se encontraron con una nota de rescate. No fue un zero-day. No fue un exploit sofisticado. Fue una llamada telefónica.

En este artículo aprenderás:

• La línea de tiempo verificada del incidente Canvas/Instructure (30 abril – 8 mayo 2026)
• El vector técnico real: cómo el grupo ShinyHunters (UNC6040) entra sin explotar ninguna vulnerabilidad
• Mapeo MITRE ATT&CK del ataque y por qué MFA no es suficiente
• Controles concretos del NIST CSF y de Google Threat Intelligence para detectar y prevenir
• Qué revisar hoy en tu propio entorno SaaS si manejas datos sensibles

Elegir multi-tenancy mal el día 1 te cuesta 6 meses de refactor el día 400. Es una de esas decisiones arquitectónicas que parecen inocuas al principio — "solo agregamos un tenantId a todas las tablas" — y que 18 meses después se revelan como la razón por la cual tu SaaS no puede cumplir un requisito de aislamiento de datos de un cliente grande, no puede migrar tenants entre regiones, o no puede ofrecer self-hosted a un cliente que lo exige.

Para un SaaS B2B que arranca en 2026, las dos arquitecturas serias son schema-per-tenant y Row-Level Security (RLS). La tercera opción, "base de datos separada por tenant", se reserva para clientes enterprise con contratos específicos y no es el default. Elegir entre schema-per-tenant y RLS no es técnica pura: es también una decisión de negocio sobre cuántos tenants vas a tener, qué tamaño, y qué compromisos de aislamiento necesitás firmar.

Este post compara ambas con código funcional, benchmarks reales y los criterios de decisión que usamos en MeepLab cuando un cliente nos pregunta "¿cómo hacemos multi-tenancy?". Todo con PostgreSQL puro, Prisma y Express — cero dependencias SaaS de pago ni ORM propietario.

En este artículo aprenderás:

• Los tres modelos de multi-tenancy y cuándo descartás cada uno
• Schema-per-tenant explicado: cómo implementarlo en PostgreSQL, fuerzas y límites operacionales
• Row-Level Security con PostgreSQL: CREATE POLICY, middleware Express y cómo funciona internamente
• Benchmark real de ambos patrones con 100 tenants y 10M filas
• Criterios de decisión: 8 preguntas que respondés antes de elegir
• Cuándo migrar de un modelo al otro y cuánto cuesta

prisma migrate deploy en una tabla de 50 millones de registros es decir "qué podría salir mal" en producción. Esa migración tan inocente que localmente tomó 200 milisegundos, en producción con un índice que se reconstruye, una columna que se llena con default, y requests concurrentes golpeando la misma tabla, puede tomar 40 minutos de lock exclusivo. Cuarenta minutos durante los cuales ningún usuario puede loguearse, ningún pago se procesa, y el canal de Slack de operaciones se llena de capturas de pantalla de errores 500.

El problema no es Prisma. Es cualquier migración naive contra una tabla grande en producción. Postgres y MySQL tienen operaciones que bloquean la tabla completa mientras corren: agregar una columna con default no nullable, cambiar el tipo de una columna, renombrar algo que está referenciado. Si corrés esas operaciones contra una tabla de millones de filas y un load balancer que no para de mandar tráfico, el sistema se congela.

El patrón que resuelve esto no es nuevo. Se llama expand-contract (también conocido como parallel change) y es la técnica estándar que usan equipos como GitHub, Shopify y Stripe para cambiar esquemas sin cortar el servicio. La idea: cada migración se divide en cuatro fases pequeñas que individualmente son seguras, corren en segundos, y se pueden desplegar gradualmente con feature flags.

En este artículo aprenderás:

• Qué operaciones bloquean la tabla en PostgreSQL y cuáles no (la lista corta y exacta)
• El patrón expand-contract en 4 fases: Expand → Migrate → Contract → Cleanup, con ejemplo real en Prisma
• Backfill batched para mover datos de una columna vieja a una nueva sin saturar la base de datos
• Rollback seguro en cada fase si algo falla a mitad del deploy
• Checklist de migración que usamos antes de tocar producción

Datadog te cobra 31 dólares por host. Tu startup de 12 servicios acaba de gastar runway en logs antes de facturar al primer cliente. Y la peor parte no es el precio: es que la mayoría de los equipos que pagan por un SaaS de observabilidad carísimo no entienden qué están midiendo. Pagan por dashboards que nadie abre, por alertas que todos silencian, y por retention de 30 días de datos que nunca consultan.

Auditoría técnica real de un backend Node.js de PyME no necesita un contrato enterprise de Datadog. Necesita responder a 12 preguntas específicas que revelan la madurez operacional del sistema. Las hemos estandarizado en el health-check que corremos antes de aceptar un cliente de backend: si el sistema falla en más de 4 de esas 12, la conversación cambia de "optimizamos" a "reconstruimos la capa de observabilidad antes de tocar la lógica de negocio".

Todo el stack que cubrimos es open source, se autohospeda en un VPS de 20 dólares al mes, y reemplaza el 90% de las funciones de Datadog/New Relic para el tamaño de operación típico de una PyME. No es un ejercicio académico: es el stack que corremos nosotros mismos.

En este artículo aprenderás:

• Las 12 señales del health-check que auditamos en cualquier backend Node.js: logs, traces, métricas, errores, latencia y más
• Stack OSS completo: OpenTelemetry + Prometheus + Grafana + Loki + Tempo, con docker-compose.yml funcional
• Qué instrumentar primero si solo tienes 2 horas antes de la próxima reunión con el CFO
• Alertas mínimas que cualquier backend en producción debería tener antes de dormir tranquilo
• Cuándo sí conviene un SaaS pagado — y cuándo es desperdicio de dinero

Tu webhook que "a veces falla" no falla a veces. Falla siempre que importa. Cuando el evento es una confirmación de pago de Stripe que el usuario ya vio en pantalla, cuando es un acuse del SAT que te notifica que el CFDI pasó a timbrado, cuando es un cambio de status de un envío que el cliente está esperando. En esos momentos tu receptor de webhooks está ocupado, la base de datos está lenta, o un deploy reciente rompió una ruta, y pierdes el evento. El emisor reintenta dos o tres veces con suerte, después te marca como "endpoint no confiable" y abandona.

Recibir webhooks bien no es tener un POST /webhook que responde 200. Es aceptar el evento en menos de 5 segundos sin importar qué, validar la firma, evitar procesar el mismo evento dos veces si llega duplicado, y procesarlo en background con reintentos exponenciales cuando falla. Todo eso se puede hacer con Node.js, Redis y BullMQ en menos de 300 líneas de TypeScript.

En este artículo aprenderás:

• Por qué los webhooks fallan en producción y qué contrato implícito tiene tu endpoint con cada emisor
• Patrón receive-fast-process-async con BullMQ para aceptar el evento en menos de 1 segundo
• Firma HMAC SHA-256 implementada bien, con comparación resistente a timing attacks
• Idempotencia por idempotency-key con Redis para no procesar el mismo evento dos veces
• Retries con backoff exponencial y Dead Letter Queue para los eventos que fallan persistentemente
• Ejemplo real con SAT PAC y Stripe para aterrizar los patrones en casos conocidos

Tu landing "se ve bien". Lighthouse dice que tus usuarios se van antes de que cargue el hero. El problema no es estético: una landing que tarda 5 segundos en pintar el LCP en 4G pierde al 53% de sus visitantes antes siquiera de ver tu propuesta de valor (Google Web.dev, 2024). Y esa métrica no la mide tu sensación de "el sitio carga rápido" en una Mac con fibra óptica. La mide un móvil Android de gama media en un pueblo con 3G inestable. La audiencia real.

Lighthouse es la herramienta open source de Google que te da ese diagnóstico honesto. Es gratis, se ejecuta local o en CI, y te devuelve un reporte con los cinco indicadores que importan: LCP, INP, CLS, TBT y FCP. Pero lo interesante no es correr Lighthouse una vez. Es integrarlo a tu pipeline de deploy para que cada pull request falle si el score baja de un umbral, antes de llegar a producción.

En este artículo aprenderás:

• Qué mide Lighthouse exactamente y por qué separar auditoría desktop de móvil cambia todas tus conclusiones
• Core Web Vitals explicados con thresholds reales para LCP, INP y CLS — los que Google usa como señal SEO
• Integrar Lighthouse CI en GitHub Actions con budget.json para bloquear PRs que degraden el performance
• Cinco optimizaciones que suben el score rápido sin reescribir nada: preload de imágenes críticas, defer de scripts, compresión Brotli, reserved space para CLS y yield to main thread para INP
• Checklist que corremos en auditorías reales antes de aceptar un cliente de frontend

Poner express-rate-limit en tu API no es rate limiting. Es teatro de seguridad. Si tu backend corre en dos o más instancias detrás de un load balancer, cada réplica cuenta requests por separado y tu "límite de 100 req/min" se convierte en 200, 400 o 1,000 según cuántos pods escales. El atacante no nota la diferencia. Tu base de datos sí.

El rate limiting serio vive fuera del proceso: en un almacén compartido que todas las réplicas consultan de forma atómica. Ese almacén, en la práctica, es Redis. Y el algoritmo correcto casi nunca es el contador fijo que viene por defecto en las librerías populares: es el sliding window log, que cuesta más en memoria pero no deja ventanas de abuse entre segundos.

En este artículo aprenderás:

• Por qué express-rate-limit con memoria local falla en arquitecturas con más de una instancia
• Los tres algoritmos clásicos (fixed window, sliding window log, token bucket) explicados con sus trade-offs reales
• Implementación paso a paso de sliding window log con ioredis y TypeScript, con operaciones atómicas
• Cómo medir si funciona usando autocannon para simular ráfagas y ver cuándo se rompe
• Checklist de producción con los errores que hemos visto en auditorías reales a APIs Node.js

El 90% de las PyMEs que nos contactan tienen el mismo problema: su sistema fue diseñado para 10 usuarios. Ahora tienen 200. La aplicación se cae los lunes a las 9am cuando todo el equipo entra. Los reportes tardan 45 segundos. Agregar una funcionalidad nueva toma 3 meses porque "todo está conectado con todo".

No es un problema de código. Es un problema de arquitectura.

La arquitectura de software es la decisión técnica más importante — y más ignorada — en proyectos de PyMEs. Es la diferencia entre un sistema que crece contigo durante 5 años y uno que tienes que tirar y rehacer cada 18 meses.

En esta guía vas a aprender:

• Por qué la arquitectura importa aunque seas una PyME
• 4 patrones de arquitectura y cuál le conviene a tu empresa
• El stack tecnológico recomendado para PyMEs mexicanas en 2026
• Decisiones de arquitectura que impactan directamente tu cartera
• El error más caro que cometen las PyMEs (y cómo evitarlo)
• 5 preguntas para evaluar si tu proveedor realmente sabe de arquitectura

El ERP promedio de una empresa mediana está conectado con 4-6 sistemas adicionales. E-commerce, CRM, facturación electrónica, bancos, logística. Pero en muchas empresas mexicanas, esas conexiones son manuales: alguien exporta un CSV de un lado e importa en otro.

Cada proceso manual es un punto de falla. Cada hora dedicada a sincronizar datos es una hora que no genera valor. Y cuando la información no fluye automáticamente, las decisiones se toman con datos incompletos o desactualizados.

Esta guía está diseñada para CTOs, gerentes de TI y tomadores de decisión técnica que necesitan entender cómo integrar su ERP con el resto de su ecosistema tecnológico.

En esta guía aprenderás:

• Por qué los ERPs aislados cuestan dinero (y cuánto)
• Tipos de integración: API, middleware, batch
• Patrones comunes: SAP ↔ E-commerce, ERP ↔ CRM
• Errores técnicos a evitar
• Stack tecnológico recomendado
• Caso real de integración exitosa

"Necesitamos microservicios porque es lo que usan Netflix y Amazon."

He escuchado esta frase decenas de veces. Y casi siempre viene de equipos de 3-10 desarrolladores que mantienen una aplicación con unos miles de usuarios.

Netflix tiene miles de ingenieros y millones de usuarios concurrentes. Tu PyME no es Netflix. Y está bien.

El mercado de microservicios cloud se triplicará entre 2020 y 2026. Serverless está creciendo exponencialmente. Kubernetes es el estándar de facto. Pero eso no significa que tu próximo proyecto deba usar estas tecnologías.

En este artículo, sin buzzwords ni hype, vamos a analizar cuándo cada arquitectura tiene sentido para equipos reales con recursos limitados.

En este artículo aprenderás:

• Por qué la mayoría de los proyectos de microservicios en PyMEs fracasan
• Cuándo un monolito bien diseñado es la respuesta correcta
• Cuándo SÍ necesitas microservicios
• El patrón intermedio que deberías considerar: Modular Monolith
• Serverless: ¿alternativa o complemento?
• Un checklist de decisión arquitectural