Qué es una actualización optimista

Entre el instante en que un usuario pulsa un botón y el instante en que el servidor confirma que la operación tuvo éxito hay un abismo de tiempo: la latencia de la red. Cien, doscientos, quinientos milisegundos en los que, si la interfaz espera de brazos cruzados con un spinner, la aplicación se siente lenta y torpe. Una actualización optimista rellena ese abismo con una predicción: en lugar de aguardar la confirmación, la interfaz pinta de inmediato el resultado que espera obtener, apostando a que la operación tendrá éxito. El corazón de “me gusta” se enciende antes de que el servidor lo sepa; el mensaje aparece en el chat antes de salir del dispositivo. Es una mentira controlada y casi siempre cierta, y es exactamente lo que separa las interfaces que responden a la velocidad del pensamiento de las que responden a la velocidad de la red.

El abismo de la latencia

El modelo pesimista es el instinto por defecto: el usuario actúa, disparas la petición, muestras un spinner, y solo cuando la respuesta llega actualizas la interfaz. Es correcto por construcción —nunca enseñas algo que el servidor no ha confirmado— pero paga ese rigor con tiempo. La investigación clásica sobre percepción humana marca una frontera dura alrededor de los cien milisegundos: por debajo, una respuesta se siente instantánea; por encima, el usuario percibe una demora y su atención empieza a fugarse. Un viaje de ida y vuelta a un servidor rara vez baja de esa cifra, y bajo una red móvil mediocre la supera con holgura. La estrategia pesimista, por tanto, condena cada interacción a sentirse más lenta que el pensamiento que la originó.

La actualización optimista invierte el orden. En lugar de actuar al final —cuando el servidor responde— actúa al principio: pinta el resultado esperado de inmediato y lanza la petición en segundo plano.

// Pesimista: la UI espera a la red
async function darMeGustaPesimista() {
  setCargando(true);
  const real = await api.darMeGusta(postId); // el usuario espera aqui
  setMeGusta(real.meGusta);
  setCargando(false);
}

// Optimista: la UI se adelanta a la red
async function darMeGustaOptimista() {
  setMeGusta(true);            // 1. predice y pinta ya
  await api.darMeGusta(postId); // 2. confirma despues, en segundo plano
}

La diferencia no es de rendimiento medido en el servidor —ambas peticiones tardan lo mismo— sino de rendimiento percibido, que es el único que el usuario siente.

La apuesta: predecir sin preguntar

El optimismo no es gratis ni universal: descansa sobre una condición estricta. Para mostrar el resultado antes de que el servidor lo confirme, tienes que ser capaz de calcularlo en el cliente sin consultarlo. Alternar un “me gusta” cumple la condición de sobra: sabes que el nuevo estado es true y que el contador sube en uno. Añadir una tarea a una lista también: conoces su texto y su posición. Pero hay resultados que el cliente no puede predecir —el identificador real que asignará la base de datos, una marca de tiempo del servidor, un total recalculado a partir de datos que no tienes— y ahí el optimismo es parcial o directamente imposible.

La frontera se ve mejor en código. Cuando el resultado depende solo de datos que el cliente ya posee, la predicción es una función pura del estado actual; cuando depende de algo que vive únicamente en el servidor, no existe función que la produzca.

// Predecible: funcion pura del estado que ya tienes
function trasAlternar(post: Post): Post {
  return {
    ...post,
    meGusta: !post.meGusta,
    likes: post.likes + (post.meGusta ? -1 : 1),
  };
}

// Impredecible: el id real y la fecha de creacion los pone el servidor.
// No hay forma de calcularlos en el cliente, solo esperarlos.
// const creada = await api.crear(texto);

Y esa seguridad es, en el fondo, estadística. El optimismo apuesta a la tasa base: la inmensa mayoría de las mutaciones tienen éxito. Pulsar “me gusta” casi nunca falla; guardar un borrador casi siempre funciona. Optimizas para ese noventa y nueve por ciento y tratas el uno por ciento restante —el fallo— como una excepción que hay que manejar con cuidado, no como el caso común que dicta el diseño. Las tres lecciones siguientes son, precisamente, el manejo disciplinado de ese uno por ciento.

flowchart TD
U[usuario pulsa] --> P[camino pesimista]
U --> O[camino optimista]
P --> PS[spinner y espera de red]
PS --> PR[respuesta llega y se pinta]
O --> OR[render inmediato de la prediccion]
OR --> OB[peticion viaja en segundo plano]
style PS fill:#f38ba8,color:#11111b
style OR fill:#a6e3a1,color:#11111b

La ventana de incertidumbre

Entre la predicción y la confirmación se abre una ventana de tiempo en la que un dato vive en un limbo: se muestra al usuario, pero no está garantizado. Modelar ese limbo de forma explícita, en lugar de fingir que no existe, es lo que separa un optimismo robusto de uno frágil. Un dato optimista no tiene dos estados sino tres, y nombrarlos como un tipo revela de golpe todo el trabajo que queda por hacer en el resto del nivel.

// El ciclo de vida de un dato optimista, hecho tipo
type Optimista<T> =
  | { estado: "confirmado"; valor: T }             // el servidor dijo si
  | { estado: "pendiente"; valor: T; previo: T }   // prediccion + snapshot
  | { estado: "fallido"; valor: T };               // hay que revertir a previo

Ese previo que aparece en el estado pendiente no es decorativo: es la memoria del pasado que hará posible la reversión, y le dedicamos una lección entera. El paso de pendiente a confirmado es la reconciliación; el paso a fallido es el rollback; y qué ocurre cuando dos clientes escriben a la vez sobre el mismo dato es el problema de los conflictos. Las cuatro lecciones restantes no son más que las transiciones de esta pequeña máquina de estados, estudiadas una a una.

Optimista frente a pesimista

Conviene ver las dos estrategias como los extremos de un mismo eje, no como opciones enemigas. El pesimismo prioriza la correctitud: no muestra nada que no esté confirmado, al precio de la demora. El optimismo prioriza la responsividad: muestra la verdad probable ahora y la reconcilia después, al precio de una divergencia temporal entre lo que ve el usuario y lo que sabe el servidor. Entre ambos hay matices —deshabilitar el control mientras se guarda, mostrar el resultado pero con una señal discreta de “guardando”— y elegir el punto correcto del eje es una decisión de diseño, no un dogma.

La elección entre uno y otro no es de temperamento del programador, sino de la naturaleza de la operación: cuánto tarda, cuán predecible es su resultado, cuán reversible es su fracaso y cuánto le importa al usuario que sea inmediata. Guardar la posición de un cursor pide optimismo sin dudarlo; transferir dinero pide lo contrario.

El punto medio más habitual combina ambas actitudes: pinta el resultado de inmediato pero bloquea el control mientras la confirmación viaja, para impedir un segundo envío antes de conocer el desenlace del primero.

// Punto intermedio: optimista pero con el control bloqueado hasta confirmar
async function guardar(nuevo: Valor) {
  setGuardando(true); // bloquea el boton: evita el doble envio
  setValor(nuevo);    // pinta ya, sin esperar a la red
  try {
    await api.guardar(nuevo);
  } finally {
    setGuardando(false); // libera al confirmar o al fallar
  }
}