Mi primer SaaS de gestión de suscripciones: ¿Feedback sobre la arquitectura?

Opera

¡Hola a todos! Después de 6 meses de desarrollo en solitario, por fin he lanzado la beta de SubHub, una herramienta para que pequeños negocios gestionen sus suscripciones recurrentes sin volverse locos con hojas de cálculo.

Actualmente uso Django + DRF para el backend, PostgreSQL y React con Vite para el frontend. Todo dockerizado y desplegado en un VPS de Hetzner. He implementado un sistema de webhooks para Stripe y un panel de métricas en tiempo real con Celery + Redis.

Mi gran duda es si estoy sobre-ingenierizando. Siento que para un MVP, el uso de Celery para tareas asíncronas puede ser matar moscas a cañonazos. ¿Debería haber empezado con algo más simple como cron y luego escalar? Me gustaría saber vuestra opinión y si alguien ha pasado por algo similar. ¡Gracias!

ArtLover

¡Enhorabuena por el lanzamiento! La verdad es que la pinta es muy buena. Sobre tu duda, no creo que sea sobre-ingeniería. Si ya tienes pensado que los webhooks de Stripe y las tareas recurrentes son el core de tu negocio, Celery es el estándar y te ahorrará dolores de cabeza cuando quieras reintentar tareas fallidas o programar cosas complejas.

¿Has pensado en usar django-q2? Es mucho más ligero que Celery, usa la misma base de datos y para un MVP va sobrado. Yo lo usé en un proyecto similar y no he vuelto atrás.

Indie

No estoy de acuerdo con lo de django-q2. Si ya tienes Redis montado, Celery no te añade casi complejidad extra y el ecosistema es mucho más maduro. Lo que sí me parece overkill es el panel de métricas en tiempo real. ¿De verdad necesitas real-time para un SaaS de suscripciones? Con un simple dashboard que se actualice cada 5 minutos vas sobrado.

Por cierto, ¿cómo gestionas la concurrencia en los webhooks de Stripe? Yo tuve un problema de race conditions al actualizar el estado de una suscripción y me volvió loco.

Opera

Gracias por los comentarios. Tienes razón en lo de las métricas en tiempo real, quizá me dejé llevar por el hype. De momento lo voy a dejar porque ya está implementado, pero lo tendré en cuenta para futuras features.

Sobre la concurrencia en los webhooks, uso una transacción atómica con select_for_update en Django para bloquear la fila de la suscripción mientras se procesa el evento. También verifico la firma del webhook y guardo un idempotency key en Redis para evitar procesar el mismo evento dos veces. ¿Te sirve eso?

BoardGames

Buena solución lo del idempotency key. Yo lo hice parecido pero con una tabla en la base de datos en lugar de Redis. Aunque Redis es más rápido, claro.

Volviendo al tema de la arquitectura, ¿has pensado en migrar a un monolito modular? Django ya te lo permite de serie. A veces veo proyectos que empiezan con microservicios y es un infierno. Tu enfoque actual me parece muy sensato para un indie hacker.

¿Tienes pensado abrir el código o hacer un build in public más detallado? Me encantaría ver cómo has estructurado los modelos.

Opera

¡Me alegra que te guste! De momento el código es cerrado, pero estoy documentando todo el proceso en mi blog y en Twitter. La idea es compartir los trade-offs y los errores que voy cometiendo.

Respecto a los modelos, he separado la lógica de negocio en una capa de services para que las vistas queden limpias. Si al final hay suficiente interés, igual libero una parte del código como open source.

Transit

Me parece muy bien lo de la capa de servicios. Es un patrón que no se ve lo suficiente en proyectos Django y luego pasa lo que pasa: vistas de 500 líneas.

Una última cosa: ¿cómo manejas los timezones? Es un dolor de cabeza cuando tienes clientes en varios países. Yo uso pytz y almaceno todo en UTC, pero a la hora de mostrar las fechas de facturación siempre hay algún lío.