Sistemas backend que aguantan tráfico real
Servicios orientados a eventos, APIs y workers asíncronos en Go, Python y TypeScript, con los casos de falla resueltos de entrada en lugar de descubiertos después.
Hablar con un ingenieroCuándo nos llaman
- La API anda bien hasta que el tráfico se duplica, y nadie sabe qué parte cede primero.
- Una cola se traba de madrugada y el mismo trabajo corre dos veces, así que a un cliente le cobran dos veces.
- Una integración externa deja de responder y voltea un flujo que no tenía nada que ver.
- Agregar una función implica tocar seis servicios, y cada release es un pequeño acto de fe.
- Hay que partir un monolito, y el intento anterior lo dejó más lento y más difícil de depurar.
Qué construimos
Servicios orientados a eventos
Productores y consumidores sobre Kafka, RabbitMQ o SQS, con contratos explícitos, garantías de orden donde hacen falta, y manejo de contrapresión cuando un consumidor no da abasto.
APIs que vale la pena integrar
Interfaces REST y gRPC con versionado y política de discontinuación, para que ni sus clientes ni sus otros equipos se rompan con el próximo release.
Workers y pipelines asíncronos
Procesamiento en segundo plano con reintentos, backoff exponencial, colas de mensajes fallidos y claves de idempotencia, para que un mensaje repetido sea inofensivo en vez de caro.
Acceso a datos que resiste
Esquemas en PostgreSQL, MySQL y MongoDB con los índices que el planificador realmente usa, más caché en Redis con estrategia de invalidación en lugar de TTL esperanzados.
Fronteras que sobreviven al cambio
Arquitectura hexagonal y DDD donde el dominio lo justifica, manteniendo la lógica de negocio separada de los frameworks y proveedores que la rodean.
Proyectos típicos
Partir un monolito sin reescribirlo
Separar el dominio de mayor riesgo en su propio servicio, definir el contrato entre lo viejo y lo nuevo, y migrar tráfico de a poco detrás de un flag. Sin cambios de golpe.
Lograr que un flujo de pagos ocurra exactamente una vez
Introducir claves de idempotencia, un proceso de conciliación y una ruta para mensajes fallidos, para que los reintentos dejen de generar cobros duplicados y toda diferencia quede visible.
Rehacer un pipeline de ingesta para volumen
Reemplazar el procesamiento sincrónico por workers en cola, agregar procesamiento por lotes y contrapresión, e instrumentar cada etapa para que los problemas de rendimiento tengan una ubicación.
Llevar una API interna a calidad pública
Sumar versionado, autenticación, límites de uso, paginación, errores consistentes y documentación, para que un socio externo integre sin abrir un ticket.
Qué se lleva
- Servicios corriendo en su infraestructura, en su repositorio, bajo su CI
- Decisiones de arquitectura escritas, con los compromisos asumidos y las alternativas descartadas
- Pruebas en los niveles que importan: unitarias para la lógica, de integración para las fronteras, de contrato para las APIs
- Instrumentación desde el primer día, no agregada después del primer incidente
- Una recorrida con sus ingenieros, para que la propiedad del código se transfiera de verdad
Preguntas que nos hacen
¿Qué lenguaje van a usar?
Go para servicios sensibles a la latencia o con mucha concurrencia, Python donde el ecosistema decide, como en datos e IA, y TypeScript cuando conviene quedarse cerca de un código Node existente. Si su equipo ya tiene un lenguaje y lo mantiene bien, usamos ese. Introducir un lenguaje que su equipo no puede mantener es un pasivo, no un servicio.
¿Pueden trabajar dentro de nuestro código actual?
Sí, y es la mayor parte de lo que hacemos. Trabajamos en su repositorio, seguimos su proceso de revisión y publicamos por su pipeline. Empezar de cero es el caso más fácil, no el más común.
¿Cómo encaran un sistema que nunca vieron?
Empezamos por una revisión de arquitectura: leer el código, recorrer los caminos críticos, mirar los incidentes y las métricas, y producir una lista priorizada de qué se rompe primero. Es a precio fijo y se sostiene sola, así que puede quedarse ahí si quiere.
Iniciar una conversación
Cuéntenos qué están construyendo, o qué se está rompiendo. Va a recibir una respuesta directa de un ingeniero, no un libreto de ventas.