La forma sigue a la función: cómo crear envíos de formularios resilientes a gran escala

Envíos de formularios

Webflow impulsa tanto a nuestros clientes como a los clientes de estos. Para muchas empresas, los embudos de ventas dependen de los envíos de formularios entrantes, por lo que la disponibilidad y durabilidad de esta función son fundamentales.

Un envío de formulario típico llega a la API de Webflow, pasa por controles de spam y se guarda en el sitio del cliente. Los clientes pueden ver y exportar estos envíos desde su panel de control de Webflow. A menudo, los clientes tienen configurados webhooks con estos formularios hacia sus propios sistemas internos, lo que les permite realizar acciones personalizadas con cada nuevo envío.

Objetivos de diseño

Nos propusimos garantizar que, incluso durante fallos en los sistemas secundarios, los envíos de formularios fueran:

1. Duraderos: nunca se pierden, incluso si falla el guardado en la base de datos
2. No bloqueantes: los mecanismos de recuperación no deben ralentizar la ruta crítica de la solicitud
3. Idempotentes: seguros para volver a procesar sin crear duplicados
4. Operables: fáciles de dirigir a un solo cliente o ejecutar en todo el sistema

Fase 1: Copias de seguridad con registro previo (Write-Ahead Backups)

La primera pregunta que debíamos hacernos era: ¿dónde deberían residir las copias de seguridad? Queríamos suficiente contexto para volver a procesar correctamente, sin añadir dependencias externas que pudieran fallar antes de que se registrara la copia de seguridad.

Optamos por colocar esto lo más arriba posible en la capa de la API, después de la validación básica del middleware, pero antes de realizar cualquier llamada a la base de datos. Al priorizar la disponibilidad de las copias de seguridad, decidimos almacenar copias de todos los envíos, incluso aquellos que luego se filtrarían como spam, así como los que se procesarían correctamente.

Decidimos usar Amazon S3 para almacenar estas copias de seguridad. Como en cualquier sistema distribuido, tuvimos que considerar qué sucedería si la solicitud de copia de seguridad fallaba y si debía ser una llamada de red bloqueante. La prioridad era servir el envío del formulario en la ruta crítica; proteger el tráfico en vivo tiene prioridad sobre el éxito de la copia de seguridad.

Fase 2: Reintento (Replay)

Con las copias de seguridad guardadas en disco, nos propusimos construir un sistema para volver a procesar los envíos de formularios en caso de una interrupción del servicio que impidiera guardarlos correctamente en la base de datos. Llamamos a este sistema replay. Esta operación debía ejecutarse en dos modos: reintento por cliente y reintento global.

Modo 1: Reintento por sitio

Este modo de reintento se ejecutaría en caso de que un solo sitio o un pequeño grupo de sitios necesitaran ser procesados nuevamente. Sería un enfoque más rápido y específico para solucionar una interrupción en el envío de formularios que afectara a un solo cliente.

Modo 2: Reintento global

Esta sería la forma más contundente de ejecutar la operación e implicaría recorrer las copias de seguridad de todos los clientes y volver a procesarlas de forma generalizada. Esta operación sería más lenta, pero se utilizaría ante una interrupción sistémica que afectara a una gran parte de los clientes.

Hashes de envío

Las interrupciones rara vez provocan el fallo del 100% de las solicitudes. Un patrón típico se ve así:

✅✅⛔✅⛔⛔✅⛔⛔⛔⛔✅

Donde ✅ representa un envío procesado correctamente y ⛔ uno que falló antes de guardarse en la base de datos. Queríamos asegurarnos de que, al repetir el proceso de principio a fin, no duplicáramos los envíos de formularios marcados con ✅ que ya habían sido procesados.

Para lograrlo, decidimos implementar un concepto llamado hashes de envío. Cada envío de formulario se representa como un hash único y estable, donde el hash SHA-256 engloba todo lo que hace que ese envío sea único: la marca de tiempo en la que entró al sistema, los datos del cliente, el cuerpo del formulario, los metadatos de la solicitud y más. Estos hashes se serializan en la ruta crítica de cada envío de formulario, independientemente del contexto de repetición.

También almacenamos y añadimos un índice de base de datos en este campo, de modo que pudiéramos consultar de forma eficiente los envíos por su hash para determinar si ya habían sido procesados con éxito.

Esto significa que, al eliminar duplicados mediante hashes de envío, pudimos crear un proceso de repetición idempotente. Así, podíamos repetir envíos en un rango amplio y asegurar que la única diferencia fueran aquellos que no se procesaron correctamente la primera vez. Además, al elegir la ventana de tiempo para la repetición, podíamos seleccionar con total tranquilidad marcas de tiempo muy anteriores y posteriores a la interrupción, garantizando que cubríamos todo el rango sin preocuparnos por procesar registros que ya estaban guardados.

const isDuplicate = await checkIfDuplicateFormSubmission({
   siteId,
   workspace,
   body,
   createdOn,
});

if (isDuplicate) {
   return;
}