Saltar a contenido

Alcance

Detrás del discurso de marketplace de excedentes, hartazone es un motor de reservas con inventario perecedero, ventanas temporales estrictas y liquidación fuera de línea. Todo el modelo gira alrededor de una única entidad crítica y de la publicación diaria que le da stock.

Las cuatro fuerzas que dominan el diseño:

  1. El tiempo es dato de negocio, no metadato. Una publicación tiene cinco instantes distintos. Casi todas las reglas son comparaciones contra esos instantes.
  2. El stock es contencioso. Retención de 2 minutos, confirmación, ajuste del comercio, cancelación, expiración y liberación concurren sobre el mismo contador. Esto se resuelve en la base de datos, no en el código de aplicación.
  3. Nada se borra. Reservas y valoraciones son inmutables o append-only por requerimiento explícito.
  4. Todo es configurable sin desplegar. Los requerimientos definen ~25 parámetros que cambian el comportamiento del motor de reservas en caliente. Los estados del ciclo de vida se rigen por el mismo principio.

Restricciones del piloto

Cinco decisiones de alcance que simplifican el modelo de forma sustancial.

Restricción Origen Consecuencia en el modelo
Pago exclusivamente en efectivo en el local RF-U-26
RF-C-45		 No hay pasarela, métodos de pago ni conciliación; el cobro es un atributo de la validación
Retiro presencial obligatorio RF-U-26 No hay direcciones de entrega, repartidores ni seguimiento
Horizonte de publicación de 48 h RF-C-24 El volumen de publicaciones vivas es trivial; no requiere particionado
Sin aplicación nativa de comercio RF-C-01 El modo contingencia es una cola de navegador; el servidor acepta la hora declarada del dispositivo pero nunca la usa para decidir
Reloj del servidor autoritativo RF-C-02 La hora del dispositivo se guarda como dato declarado, jamás como fuente de verdad

Fuera de alcance

Funcionalidad Estado
Programa de puntos por compra y canje Sin requerimiento asociado
Puntos por reciclaje de envases Sin requerimiento asociado
Regalos digitales entre usuarios Sin requerimiento asociado
Pago con tarjeta o billetera en la app Negado por RF-U-30
Declaración estructurada de alérgenos Retirado por decisión de negocio

Invariantes críticos

Cuatro garantías que no pueden fallar. Todas son estructurales: si alguna se implementa en la capa de aplicación, el requerimiento correspondiente deja de ser una garantía y pasa a ser una aspiración.

Invariante Mecanismo Requerimientos
El stock reservado nunca supera al publicado chk_publicacion_stock_coherente RF-U-31
RF-C-31
El código de reserva es único en todo el sistema unq_reserva_codigo RF-U-32
RF-C-43
Una reserva se valida a lo sumo una vez Único por construcción (OneToOneField) RF-C-44
Dos ventanas del mismo día nunca se solapan excl_ventanarecogida_solape RF-C-20

CHECK (cantidad_reservada <= cantidad_total) sobre publicacion, combinado con el ajuste del contador dentro de la misma transacción que crea la reserva, convierte la sobreventa en un error de transacción sin necesidad de SELECT ... FOR UPDATE explícito y sin ventana de carrera entre la lectura y la escritura. Es el núcleo del control de concurrencia.

La primera de las cuatro depende de que algo mueva cantidad_reservada dentro de esa transacción, y ese algo es trg_reserva_ajustar_stock. A la quinta garantía estructural del modelo, la restricción maestra que obliga a toda ventana de recogida a caber en el horario de atención de su día (RF-C-17), la impone trg_ventanarecogida_dentro_horario.

El inventario completo de lo que la base impone hoy y de lo que falta está en Triggers.

La prohibición de borrar una reserva es un régimen de tabla, no un invariante puntual. Lo impone el mismo mecanismo que protege cualquier otra tabla mutable protegida del modelo, descrito en Auditoría por tabla.