Escalabilidad y sistemas distribuidos.

Funcionaba perfecto con veinte usuarios. Después llegaron dos mil, la base de datos empezó a contestar tarde, un servicio se cayó a las tres de la mañana y nadie supo por cuál empezar a mirar. Escalar empieza por saber qué parte del sistema está pidiendo ayuda y qué parte solo hace ruido. Agregar servidores sin esa respuesta compra tiempo y poco más.

CosaSeria atiende sistemas que ya están en producción y han dejado de ser pequeños. El servicio cubre rendimiento, confiabilidad, observabilidad y operación: medir antes de cambiar, cambiar lo que la medición señala y dejar al equipo con las herramientas para ver venir el siguiente cuello de botella.

Problemas que atiende

• Latencia que crece con el tráfico y nadie sabe en qué capa se gasta el tiempo.
• Una base de datos que se convirtió en el único punto de contención de todo el sistema.
• Fallos parciales: un componente lento arrastra al resto porque no hay timeouts, límites ni degradación controlada.
• Caídas que se detectan cuando un cliente avisa, por falta de métricas, trazas y alertas que signifiquen algo.
• Costos de infraestructura que suben más rápido que el uso.

Cuándo conviene

• Cuando el crecimiento ya llegó o está agendado (un lanzamiento, una temporada, un contrato grande) y el sistema no ha sido probado a ese nivel.
• Cuando los incidentes se repiten y las soluciones son reiniciar o agregar máquinas.
• Cuando el equipo opera un sistema distribuido sin observabilidad distribuida y depurar se volvió adivinar.
• Cuando una parte del sistema tiene un perfil de carga claramente distinto al resto y hay que decidir si aislarla.

Cómo trabajamos

1. Medir primero. Perfilado, trazas y métricas sobre el sistema real con carga real. Se busca el cuello de botella con evidencia, antes de tocar el componente que más sospechas despierta.
2. Atender la cola larga. La petición más lenta manda. Se revisan latencia por percentil, reintentos, idempotencia y qué ocurre cuando una dependencia no contesta.
3. Corregir en orden de impacto. Índices, consultas, cachés, colas, límites de concurrencia, particionado. Lo más barato que resuelva el problema medido va primero; partir el sistema va al final.
4. Diseñar para fallar bien. Timeouts, bulkheads, circuit breakers y degradación controlada, para que un fallo parcial siga siendo parcial.
5. Dejar observabilidad. Tableros, alertas y trazas que el equipo entienda y mantenga. Un sistema que escala y nadie puede ver es un problema aplazado.

Qué entregamos

• Informe de diagnóstico con mediciones reproducibles y el cuello de botella identificado.
• Cambios implementados o especificados, priorizados por impacto y riesgo.
• Instrumentación: métricas, trazas y alertas con umbrales justificados.
• Pruebas de carga y los criterios para repetirlas antes del siguiente salto de tráfico.
• Guía de operación: qué mirar, qué significa y qué hacer cuando se dispara una alerta.

Sobre los resultados. No se prometen porcentajes ni plazos antes de entender el problema. Los números se publican cuando se puede decir exactamente qué miden, en qué periodo y quién los verificó.

Evidencia relacionada

Buena parte del costo oculto de escalar está en la red entre componentes. La nota Microservicios: cuándo no detalla qué aparece cuando cada llamada de función se convierte en una llamada remota: fallos parciales, latencia de cola larga, idempotencia obligatoria y consistencia eventual.

El fundador trabajó en sistemas con tráfico global en Amazon, entre ellos la plataforma de traducción de reseñas de clientes, y en plataformas de pagos. Ese trabajo fue como empleado y está descrito con sus límites de confidencialidad en Trabajo.

Preguntas frecuentes

¿Necesitamos microservicios para escalar?

Casi nunca es lo primero. Un mismo binario desplegado en dos grupos de máquinas con responsabilidades distintas ya escala por partes. Partir el despliegue se justifica cuando hay equipos que se bloquean entre sí o una parte con un perfil de escala genuinamente diferente.

¿Pueden trabajar sobre un sistema en producción sin detenerlo?

Ese es el caso habitual. Las mediciones se hacen sobre el sistema real y los cambios se despliegan por etapas, con forma de volver atrás. Detener la operación para «rediseñar» suele ser más caro que el problema original.

¿Qué nube o herramientas usan?

Las que ya tiene el cliente, salvo que el diagnóstico diga lo contrario. El cuello de botella rara vez está en la marca del proveedor.

¿Incluye reducir costos de infraestructura?

Cuando el diagnóstico lo permite, sí. Un sistema que gasta recursos en reintentos, consultas sin índice o máquinas sobredimensionadas suele abaratarse al corregir el problema de rendimiento. Se mide antes y después, sin prometer un porcentaje de antemano.

---

Otros servicios. Arquitectura de software · Software a medida · Inteligencia artificial · Technical advisory.