Lunes, 09:14 — La Lista de Deseos en la Pared

Lukas estaba en su elemento cuando tenia un marcador en la mano.

Trazo una flecha gruesa, ascendente, a la derecha de la pizarra, rematada por un circulo en negrita: Q3: 2.5x DAU.

—Aqui es donde tenemos que estar en septiembre —dijo, golpeando el circulo con el marcador—. El evento de verano demostro que la demanda existe. Las campanas de Claudia convierten como nunca. Pero para retener a la gente necesitamos funciones: lobbies en tiempo real, matchmaking global, un sistema de torneos en vivo.

Pego tres notas rosas fluorescentes en la pizarra.

Katja no miro las notas. Miro su portatil, donde Navigator mostraba otro tipo de verdad.

—Lukas —dijo con su tono bajo y seco, el que usaba cuando iba a hablar de fisica—, apenas sobrevivimos el fin de semana pasado. El ajuste del connection pool de Hassan y las pruebas de invalidacion de cache de Mariana son la unica razon por la que los servidores no se derritieron. No tenemos infraestructura para matchmaking global, mucho menos para torneos en vivo.

—Sobrevivimos —respondio Lukas, girandose hacia ella—. Ese es el punto. El equipo reacciono. Parcheamos. Asi funciona live ops.

—No —corto Katja, cerrando el portatil con un clic suave—. Eso fue apagar incendios. Live ops deberia ser una quema controlada, no una alarma total con mi lider de backend escribiendo pruebas a medianoche.

Stefan observo como se tensaba la mandibula de Lukas. Habia visto esa dinamica demasiadas veces: producto persiguiendo la siguiente cifra de crecimiento y desarrollo explicando que el cimiento ya se esta agrietando.

—Tenemos que crecer, Katja —dijo Lukas, con la voz mas grave—. El consejo esta mirando Q2. Si no mostramos una ruta clara de retencion para Q3, la siguiente ronda de financiacion va a doler. No podemos pasar tres meses refactorizando.

—No es refactorizacion —dijo Stefan, apartandose del marco de la ventana—. Es realismo operativo. Estas planeando una carrera de alta velocidad en una pista que no esta pavimentada.

Lukas se giro hacia el. —La pista si esta pavimentada. Tenemos staging. Tenemos pruebas de carga.

—Teneis un staging que no refleja produccion —respondio Stefan—. Y vuestro test de carga es un script contra un nodo unico de base de datos con datos simulados que no representan comportamiento real. Eso no es una pista. Es un dibujo de una pista.

Lukas miro las notas rosas y volvio a Stefan. —No tenemos el lujo de esperar. Hay que estimar estas funciones. Si el equipo dice que se puede, se hace.

—Y si estan estimando bajo la suposicion de que la pista ya existe? —pregunto Katja.

—Lo veremos en la sesion de estimacion —dijo Lukas, tapando el marcador—. Martes por la tarde. Veamos que dice realmente el equipo.

Martes, 14:05 — El Teatro de la Estimacion

El rincon de backend estaba caliente. El sol de la tarde golpeaba la fachada de cristal y los ventiladores movian, sobre todo, aire tibio con olor a cafe.

Mariana miraba fijamente el ticket de Jira de Global Matchmaking.

—Esto es una broma, no? —dijo, levantando la vista hacia Stefan.

—Lukas va completamente en serio —respondio Stefan.

—Solo esto son tres meses de trabajo —dijo Mariana, golpeando el boligrafo contra la mesa—. Si escribimos pruebas primero, diseniamos bien el esquema y cubrimos casos limite —split brain, latencia regional, colas de emparejamiento—, son doce semanas de trabajo continuo. Y eso asumiendo que la base de datos no revienta.

—No aguanta —dijo Sofia en voz baja, mirando su segundo monitor—. La logica actual esta acoplada a una unica base regional. Si vamos a global, necesitamos replicas de lectura en tres regiones. Tenemos que manejar el retraso de replicacion. Si no, los jugadores se emparejan pero sus estados de inventario llegan tarde y pierden objetos.

—Pues inflamos la estimacion —dijo Anton, girando su silla con medio mordisco de manzana en la mano—. Le decimos a Lukas cuarenta puntos. Grita. Negociamos a treinta. Construimos la version sucia mas simple que no se estrelle en su telefono y dejamos que Hassan arregle el retraso en produccion.

Mariana lo fulmino con la mirada. —No. Eso no otra vez. Pasamos toda la semana pasada arreglando codigo sucio por no escribir pruebas primero. No vuelvo a deploys de viernes por la noche rezando para que no se corrompa la base.

—TDD es bonito para funciones puras —dijo Anton, mordiendo la manzana—. Pero cuando Lukas quiere torneos para agosto no hay tiempo para teologia. Escribes codigo, lo subes y rezas.

—Eso no es teologia —dijo Stefan, inclinandose sobre la mampara—. Es gestion de riesgo. Si estimais una funcion sin estimar la infraestructura necesaria para que sea segura, estais mintiendo a Lukas. Y, peor, os mentis a vosotros.

Saco un rotulador y dibujo una cuadricula en el cristal.

—Visualicemos dependencias —dijo Stefan—. Para construir Global Matchmaking, que hace falta primero?

—Replicas de lectura —respondio Sofia.

—Y para probar esas replicas?

—Paridad de staging —dijo Mariana—. No puedes probar retraso de replicacion en local. Necesitamos un staging que realmente refleje una topologia multirregion.

—Y cuanto tarda Hassan en montar ese staging? —pregunto Stefan.

La sala quedo en silencio. Solo se oia el zumbido del rack y el traqueteo lejano del U-Bahn.

—Hassan ya trabaja sesenta horas semanales —dijo Mariana, bajando la voz—. Si le pedimos staging multirregion y mantener live ops al mismo tiempo, se quema. O se va.

Anton miro la cuadricula. Ya no sonreia.

—Entonces no son treinta puntos —dijo—. Es toda la infraestructura.

—Exacto —respondio Stefan—. Ahora pongamos eso en papel.

Miercoles, 10:30 — La Confrontacion

—Esto es inaceptable —dijo Lukas.

No grito, pero su voz tenia una vibracion que hacia resonar el vaso de agua en la mesa.

—Pedi estimaciones de tres funciones. Me habeis traido una propuesta para gastar las seis primeras semanas del Q3 en staging y replicas de base de datos. Eso no es una hoja de ruta, Katja. Es una huelga.

—Es un choque con la realidad —respondio Katja, dejando el diagrama sobre el escritorio—. Mira las lineas rojas. Son puntos unicos de fallo. Si construimos torneos sin paridad de staging, lanzamos algo que no podemos probar bajo carga. Va a colapsar. No con 12% de error como en canary. Con bloqueo total.

—No puedo decirle a los inversores que en julio construimos staging —dijo Lukas, caminando de un lado a otro—. No les importa staging. Les importan funciones. Les importa retencion.

—Les importara cuando la retencion caiga a cero porque el juego sera injugable durante tres dias —dijo Katja.

—Podemos mitigar —insistio Lukas—. Lanzamos en una region primero. Limitamos la entrada a torneos.

—Y como pruebas ese limite? —pregunto Stefan.

Lukas se detuvo y lo miro entrecerrando los ojos. —En produccion. Como hicimos con canary.

—Canary funciono porque teniamos fallback —dijo Stefan—. Y porque Hassan y Mariana trabajaron treinta horas seguidas escribiendo circuit breakers. No puedes construir un negocio sobre heroismo. No escala. Los heroes se cansan y se van.

Lukas miro el diagrama. Las lineas rojas unian Global Matchmaking con Paridad de Staging y Replicas de Base de Datos.

—No hay termino medio? —pregunto, ahora con voz cansada—. No podemos construir funciones e infraestructura en paralelo?

—No —dijo Katja—. Porque desarrollo necesita staging para escribir pruebas de las funciones. Si primero codifican y luego montamos infraestructura, repetimos exactamente el mismo error del evento de verano.

Lukas se sento despacio. Paso un largo rato en silencio.

—Necesito pruebas —dijo al fin—. Si voy a pedir al consejo que retrase el sistema de torneos, necesito mas que un diagrama. Necesito evidencia incontestable de que el setup actual fallara.

Katja miro a Stefan.

—Te la damos —respondio Stefan.

Jueves, 15:45 — La Prueba en los Datos

La sala de operaciones era el unico lugar frio de la oficina. El aire estaba a 18°C para evitar que los servidores de prueba se sobrecalentaran, y el zumbido constante de los ventiladores vibraba en el suelo.

Hassan no se habia afeitado en tres dias. Tecleaba como si la silla fuera una extension de su cuerpo.

—Simulamos 100.000 usuarios concurrentes intentando entrar al lobby de torneos al mismo tiempo —dijo sin levantar la vista—. Usamos los patrones reales del sabado y los escalamos al objetivo del Q3.

Pulso una tecla.

En el monitor central, la latencia de base de datos subio de forma estable y luego se disparo verticalmente hacia un rojo intenso.

—Ahi —dijo Mariana, apuntando al pico—. Agotamiento del connection pool. Con 65.000 usuarios, la base deja de responder a nuevas conexiones. Los servidores de aplicacion encolan solicitudes, sube el consumo de memoria y en noventa segundos cae todo el cluster.

Lukas se acerco mas. —Pero aumentamos el pool la semana pasada.

—A 500 —respondio Hassan—. El sistema de torneos necesita conexiones persistentes para matchmaking. No es un API call normal de conectar-leer-cerrar. Los jugadores se quedan conectados esperando partida. Con 100.000 usuarios necesitamos al menos 2.000 conexiones concurrentes. La CPU de base llega al 100% mucho antes.

—Y la cache? —pregunto Lukas.

Mariana abrio su terminal. —Aqui estan los resultados de la suite de invalidacion de cache que escribi el martes. Bajo condiciones de torneo, la invalidacion llega al 94%. Estamos saltandonos la cache casi por completo porque el estado de jugador cambia demasiado rapido. La base recibe cada solicitud.

Lukas se quedo mirando la linea roja, plana en la parte superior: congelacion total.

—Cuanto tardariamos en recuperar en produccion? —pregunto.

—Sin replicas de lectura? —dijo Hassan, alzando la vista con ojos enrojecidos—. Dos horas para levantar el cluster. Otra hora para limpiar transacciones en cola. Y probablemente perderiamos alrededor del 5% del progreso por transacciones no confirmadas.

Lukas guardo silencio. El frio de la sala parecia caerle encima.

—Esta es la evidencia que pediste —dijo Katja desde la puerta—. No estamos adivinando. Los datos dicen exactamente donde esta el muro. Podemos frenar antes o estrellarnos a toda velocidad.

Lukas se puso de pie lentamente. Miro a Hassan, luego a Mariana, y finalmente a Stefan.

—Vale —dijo—. Como se lo presentamos al consejo?

Viernes, 17:12 — El Presupuesto de la Realidad

La reunion del consejo duro tres horas.

Lukas presento personalmente. No uso la palabra “refactorizacion”. Lo llamo Operational Realism Initiative. Mostro el diagrama de dependencias, el pico de latencia y la proyeccion de perdida de ingresos de una caida de tres dias.

El consejo aprobo el presupuesto en veinte minutos.

—Ni siquiera discutieron —dijo Lukas, recostandose en la silla—. Miraron la linea roja y preguntaron si seis semanas eran suficientes.

—Los datos estabilizan conversaciones —dijo Stefan, borrando el ultimo trazo rosa del tablero—. Cuando enseñas la fisica del sistema, la discusion deja de ser opinion y pasa a ser restriccion.

Katja sonrio, esta vez de verdad. —Nos compramos seis semanas de cordura. Hassan puede construir staging. Mariana puede escribir pruebas de carga. Podemos pavimentar la pista.

—La presion no desaparece —advirtio Lukas—. Tenemos que entregar torneos para septiembre. El consejo espera ese 2.5x DAU. Solo movimos el riesgo del lanzamiento a la ejecucion.

—Ahi es donde debe estar —dijo Stefan, escribiendo STAGING PARITY en verde—. El riesgo de ejecucion se gestiona con buenas practicas. El riesgo operativo es apostar.

Miro a Katja. —El equipo esta listo. Mariana ya escribe tests para sincronizacion multirregion. Sofia esta mapeando el esquema de base. Incluso Anton pregunto hoy por pruebas unitarias para la UI de matchmaking en Unity.

—Anton? —pregunto Katja, levantando una ceja.

—Sigue llamandolo teologia —rio Stefan—. Pero quiere que su UI no quede ridicula cuando llegue el retraso de replicacion. El sarcasmo es su forma de importar.

Afuera, el cielo de Berlin tomaba ese violeta profundo de mediados de junio. Se encendian las luces junto al canal y la musica de una cerveceria cercana entraba por la ventana abierta.

Katja tomo su bolso. —Me voy a casa. Y apago el telefono hasta el lunes.

—Recomendacion excelente —dijo Stefan.

Lukas miro las notas verdes. —Seis semanas —murmuro—. No podemos desperdiciar ni un dia.

—No lo haremos —respondio Katja.

Se fue con pasos mas ligeros que en meses.

Stefan la vio salir y volvio al tablero. Las notas verdes se veian bien en la luz del atardecer. No eran vistosas. No eran glamorosas. Eran reales.

Y por primera vez desde que habia llegado a Berlin, el equipo estaba construyendo sobre suelo firme.

Navigator — Katja Müller — 19 de junio de 2026, 21:14

Semana de planificacion del Q3. La pelea mas dura del ano, y la ganamos.

Lukas presiono por una hoja de ruta agresiva —matchmaking global, torneos en vivo, lobbies en tiempo real— sin abordar la deuda de infraestructura acumulada desde Q1. Queria creer que sobrevivir el evento de verano significaba estar listos para escalar.

Stefan y yo forzamos la confrontacion. El diagrama de dependencias mostro que cada funcion estaba bloqueada por la falta de paridad de staging y replicas multirregion. El punto de inflexion fue la prueba de carga: Hassan y Mariana simularon la carga objetivo y mostraron exactamente donde colapsaba el connection pool.

El consejo aprobo la “Operational Realism Initiative” sin resistencia. Tenemos seis semanas para construir staging serio, pruebas de carga automatizadas y replicas de lectura.

Senales de Navigator esta semana:

• 100% de los commits de backend incluyeron archivos de pruebas.
• La precision de las estimaciones mejoro cuando el equipo hizo explicitas las dependencias en el panel de cristal.
• Las horas registradas de Hassan bajaron a 42, una mejora masiva frente a las semanas de 60+ durante el evento.
• Anton esta entrando en TDD y pide ayuda para pruebas unitarias de la UI de matchmaking en Unity bajo retraso de replicacion.

Hemos comprado tiempo y margen de maniobra. El riesgo de ejecucion sigue alto. Tenemos seis semanas para pavimentar la pista antes de correr.

Si no construimos paridad de staging ahora, no tendremos una segunda oportunidad.

Por esta noche, el telefono queda apagado.

Esta es una obra de ficcion. Nombres, personajes, empresas, eventos e incidentes son producto de la imaginacion del autor. Cualquier parecido con personas reales, vivas o muertas, o eventos reales es pura coincidencia. Caimito Navigator es un producto real mencionado en esta narrativa de ficcion.