Pickop
Rewrite completo desde cero de una plataforma de pedidos por WhatsApp. Diseñé el backend NestJS con una cadena de guards explícita (rate limiting → JWT → entitlements → permisos) y un sistema RBAC con wildcards que resuelve permisos por rol y por addon contratado. Los pedidos llegan cifrados end-to-end vía WhatsApp Flows (RSA-OAEP-256 + AES-GCM) y el panel se actualiza en tiempo real por Supabase Broadcast sin pasar por el backend. La facturación de la suscripción soporta Stripe, PayPal y Binance Pay detrás de una interfaz común de proveedor de pago.
Cifrado de WhatsApp Flows
Meta exige que el payload de los formularios interactivos viaje cifrado end-to-end y que la clave pública rote sin downtime. Solución: envoltura RSA-OAEP-256 de una clave AES-GCM efímera por request, con manejo explícito del código 421 para servir la nueva clave pública sin interrumpir flujos en curso.
Multi-tenancy y planes por addon
Cada restaurante contrata módulos distintos (finanzas, reviews, warehouse) y el acceso debe evaluarse en cada request sin penalizar latencia. Solución: EntitlementsGuard que cachea en Redis los addons activos por tenant y distingue en la respuesta si el 403 es por addon no comprado o por módulo fuera de plan.
Cadena de guards explícita
Throttler → JwtAuth → Entitlements → Permission, registrados globalmente y documentados en el orden exacto en que se ejecutan, cada uno actuando solo si el handler lleva el decorator correspondiente. El restaurant_id siempre se resuelve desde el JWT, nunca se acepta desde el body o query del cliente.
Pasarelas de pago intercambiables
Interfaz PaymentProvider (createCharge/queryCharge/verifyWebhook/parseWebhook) implementada por Stripe, PayPal y Binance Pay y registrada en un PaymentProviderRegistry, de forma que el servicio de facturación nunca conoce el proveedor concreto. Cada webhook se verifica por firma antes de procesarse de forma asíncrona.