Caso · Eventos deportivos de motor
Venta y entrega de fotografía de eventos
De publicar y cobrar fotografías a mano a una plataforma de venta y entrega digital para un rally
Resumen
Problema
La publicación, la venta y la entrega de imágenes necesitaban convivir en un mismo recorrido para fotógrafos y compradores. Cobrar y entregar dependía de pasos manuales y de herramientas sin conexión entre sí.
Solución
Una plataforma propia en Django que reúne publicación, almacenamiento, compra, pago y entrega de imágenes dentro del mismo recorrido.
Resultado observado
Las imágenes, los pedidos y la entrega quedaron vinculados dentro del mismo sistema. La administración gestiona imágenes y pedidos sin depender de varias herramientas desconectadas.
Cambio observado, sin cifras publicadas. Solo publico métricas con punto de partida, periodo y fuente.
Antes y después
Qué pasos desaparecieron
«Antes» muestra cómo se hacía el trabajo y marca los pasos donde se atascaba o había que revisar a mano. «Después», el recorrido con el sistema en marcha.
Antes
- Organizar a mano las fotos de cada edición
- Compartirlas por canales separados
- Comprobar el pago de cada petición
- Buscar la imagen y enviarla
Después
- Subida por evento y categoría
- Compra y pago desde el móvil
- La pasarela confirma el pago
- Descarga habilitada
Piezas del sistema
- Panel de administración Subida y organización de imágenes y pedidos
- Colas de tareas con Redis Procesado de imágenes sin bloquear la web
- Almacenamiento en Cloudflare R2 Originales y versiones fuera del servidor
- Pasarela de pago Redsys Su notificación cambia el estado del pedido
- Pedidos y descargas Solo se habilitan para pedidos pagados
Razonamiento
Cómo se decidió qué construir
-
Situación inicial
Después de cada edición, las fotografías se organizaban y compartían a mano. El cobro y la entrega iban por caminos separados, y cada petición de un participante obligaba a buscar su imagen, comprobar el pago y enviarla.
-
Restricciones y riesgos
- La actividad se concentra en los días posteriores a cada edición, con muchas subidas y visitas en poco tiempo.
- Cada fotografía ocupa varios megas, así que el almacenamiento no podía depender del disco del servidor.
- Quien compra quiere encontrar su foto y pagarla desde el móvil en pocos pasos.
- La organización no tiene un equipo técnico y necesitaba gestionarlo desde un panel sencillo.
-
Qué se decidió
Se definió una plataforma propia con almacenamiento, pago y administración, en lugar de encadenar varias herramientas sin control común. La descarga se habilita en cuanto la pasarela confirma el pago, sin que nadie tenga que comprobarlo.
Qué se descartó. Las galerías genéricas y los servicios de venta de fotografía resolvían la publicación, pero condicionaban la estructura por evento, las comisiones y la experiencia de compra, y no se integraban con la forma de trabajar de la organización.
-
Proceso y participación
La organización explicó cómo se trabaja en cada edición y qué peticiones recibía. Yo me encargué del análisis, la arquitectura, el desarrollo, el despliegue y el mantenimiento.
-
Puesta en marcha
La plataforma se prepara antes del pico de cada edición y se mantiene entre ediciones con actualizaciones y revisión de la configuración de pagos.
-
Resultado
- Publicación, cobro y entrega dentro de un único sistema.
- Descarga disponible tras confirmar el pago, sin envíos manuales.
- Imágenes almacenadas fuera del servidor de aplicación, preparadas para crecer en cada edición.
Límites. Todavía no publico métricas de volumen por edición ni de tiempo ahorrado. La siguiente fase es medir fotografías publicadas, tiempo hasta la publicación, pedidos y entregas para decidir las mejoras con datos.
Detalle técnico Consultar arquitectura, integraciones y tecnologías
Arquitectura
- Subida y organización. La organización carga las fotografías por evento y categoría desde el panel de administración.
- Procesado en segundo plano. Las tareas pesadas sobre las imágenes se ejecutan en colas con Redis, de modo que la web sigue respondiendo mientras se procesa cada lote.
- Almacenamiento de objetos. Los originales y sus versiones se guardan en Cloudflare R2, separados del servidor de aplicación.
- Compra. El participante busca, selecciona y paga mediante la pasarela integrada.
- Entrega. Cuando la pasarela confirma el pago, el sistema habilita la descarga de las imágenes compradas.
Integraciones
- Pasarela de pago (Redsys). El estado del pedido cambia con la notificación de la pasarela. La entrega depende de ese estado.
- Almacenamiento de objetos (Cloudflare R2). La aplicación guarda y sirve las imágenes desde el almacenamiento de objetos, separado del disco del servidor.
Modelo de datos
Eventos, categorías, fotografías, pedidos y líneas de pedido. Cada pedido conserva su estado de pago y las imágenes que habilita, lo que permite revisar cualquier compra sin buscar en correos.
Seguridad y permisos
- La administración de imágenes y pedidos queda restringida al panel interno.
- Las descargas solo se habilitan para pedidos pagados.
- Las credenciales de la pasarela y del almacenamiento se gestionan fuera del código.
Decisiones técnicas: ventajas e inconvenientes
- Django por su panel de administración y su modelo de datos, que permiten construir un panel fiable sin desarrollar cada pantalla desde cero. A cambio, la interfaz pública requiere trabajo propio.
- Almacenamiento de objetos en lugar de disco local. El volumen crece por edición y no condiciona el tamaño ni las copias del servidor. A cambio, añade un proveedor externo que hay que configurar y vigilar.
- Colas para el trabajo pesado. Separar el procesado de imágenes de la petición web evita esperas y errores en los picos. A cambio, hay un componente más que desplegar y supervisar.
Despliegue y mantenimiento
Entre ediciones se revisan actualizaciones, configuración de pagos y capacidad para el siguiente pico.
Quién hizo este trabajo
Alberto Mier, consultor tecnológico y desarrollador senior. Llevo más de doce años desarrollando software para empresas, autónomos y organizaciones. Sobre mí.
Servicios relacionados