The Rollecito

The Rollecito es la plataforma de pedidos detrás de una panadería de rollos de canela en Los Ángeles. No es una plantilla de tienda: opera el negocio. Los clientes navegan un menú por sucursal, configuran y pagan un pedido, y lo siguen con un código de rastreo, mientras la cocina trabaja esos mismos pedidos en una cola en vivo y el personal administra el catálogo, las promociones y las sucursales desde un back office aparte.

Una panadería pequeña que vende un producto hecho al momento pierde dinero en dos lugares a la vez. Al frente, los pedidos llegan por llamadas y mensajes directos, se transcriben a mano y salen mal: una opción que falta, una cantidad mal escuchada, un cliente que llega antes de que algo esté horneado. Atrás, la cocina no tiene cola: tiene la nota que esté sobre el mostrador en ese momento.

El arreglo genérico es una página de pedidos de terceros. Resuelve el formulario y deja todo lo demás: sin vista de cocina, sin menú por sucursal, una comisión en cada pedido, y un catálogo que no puede expresar 'frosting de queso crema, agregar fresas, sin drizzle' sin convertir cada combinación en un producto aparte.

El pedido empieza con una sucursal, no con un producto. Elegir el local acota todo lo que sigue: qué artículos existen, cuáles están disponibles hoy y dónde se recogerá el pedido.

De ahí el cliente configura un artículo mediante sus grupos de opciones, lo agrega al carrito y paga. El checkout no requiere cuenta — pedir como invitado es una ruta de primera clase, porque obligar a registrarse a un cliente nuevo que compra un pan de seis dólares es la forma en que una panadería pierde la venta.

Tras el pago el cliente recibe un código de rastreo. La pantalla de seguimiento no es un recibo estático: está suscrita a los mismos eventos de pedido que produce la cocina, así que el estado se mueve conforme la cocina avanza.

El catálogo deliberadamente no es una lista plana de productos. Los artículos pertenecen a categorías, cargan grupos de opciones con sus propios valores, y se unen a sucursales, de modo que el mismo artículo puede existir en un local y no en otro. Los grupos de opciones se pueden clonar entre artículos, porque los toppings y frostings de una panadería se repiten en casi todo el menú y volver a capturarlos a mano es como un catálogo se desincroniza.

Los pedidos referencian el artículo configurado y sus opciones seleccionadas en vez de una cadena de producto precalculada, así que el total del pedido se puede recalcular del lado del servidor en cualquier momento y un pedido histórico se sigue explicando solo.

Un pedido pasa por cinco estados — CREATED, PAID, PREPARING, READY, COMPLETED — y las transiciones se fuerzan en la base de datos y no en el código de aplicación. Un pedido no puede saltarse un estado ni ir hacia atrás.

Esa ubicación es intencional. El mismo pedido lo tocan la tienda, el manejador del webhook y la pantalla de cocina, a veces en el mismo segundo. Si la regla vive en uno de esos llamadores solo se cumple para ese llamador; en la base de datos se cumple para todos, incluido uno futuro que todavía no se ha escrito.

La vista de cocina es una cola en vivo por orden de llegada, no un dashboard. Los pedidos pagados aparecen sin recargar, el personal los avanza por preparación y listo, y un pedido se puede priorizar o cancelar cuando la realidad lo exige.

El mismo cambio de estado que redibuja la cola de cocina también se empuja a la pantalla de seguimiento del cliente. Un evento, dos audiencias — que es la razón por la que existe la capa de tiempo real.

El personal inicia sesión por una ruta de autenticación distinta a la de los clientes, y el back office está organizado por rol: gestión de menú y opciones, sucursales, promociones, registros de clientes, historial de pedidos y reportes de ingreso.

El motor de promociones tiene un paso de vista previa, así que una regla de descuento se puede evaluar contra un pedido antes de publicarla — una salvaguarda barata contra una promoción que resulta más generosa de lo previsto una vez que se encuentra con un carrito real.

El backend se publica como imagen Docker a un AWS Lightsail Container Service; la tienda se compila y se aloja en AWS Amplify. El despliegue lo dispara GitHub Actions al hacer merge a la rama de producción, detrás de una aprobación manual obligatoria — un freno deliberado sobre un sistema que recibe pagos reales.

La API está detrás de una línea base de cabeceras de seguridad y una lista estricta de orígenes permitidos, con reCAPTCHA en las rutas que de otro modo serían atractivas para abuso automatizado.

El ingreso es directo: los clientes pagan su pedido con Stripe y la panadería se queda con la transacción en vez de una parte de ella después de la comisión de un marketplace. Ser dueño del checkout también significa ser dueño de la relación con el cliente, del catálogo y del precio — incluidas las promociones, que son parte de primera clase del sistema y no algo que se aplica a mano en el mostrador.

La misma fila de pedido la escriben tres actores independientes. El cliente la crea y puede reintentar. Stripe la confirma de forma asíncrona, posiblemente entregando el mismo webhook más de una vez. La cocina la avanza mientras las otras dos siguen en vuelo.

Cualquier par de ellos puede llegar en el orden equivocado o dos veces. Un webhook que aterriza después de que un miembro del personal ya empezó a preparar no debe regresar el pedido a PAID; una entrega duplicada no debe registrar el pago dos veces; un cliente que reintenta el checkout no debe crear un segundo pedido vivo para el mismo intent.

La respuesta fue dejar de tratar la corrección como responsabilidad de cada llamador. Los registros de pago son idempotentes, así que un webhook repetido no hace nada, y la máquina de estados la fuerza la base de datos, así que una escritura fuera de orden se rechaza en vez de ser meramente improbable. Ese es el razonamiento detrás de la capa de procedimientos almacenados: es el único lugar por el que los tres escritores necesariamente pasan.