001 · Technical case study
B2B platform con aislamiento estricto por organización, dual-layer payments (suscripción de plataforma + cuentas conectadas con split-payouts) y una capa de integraciones OAuth extensible a cualquier proveedor.
By the numbers
Snapshot of the production repo — counted directly from source.
Migrations
35 central · 67 tenant
Eloquent models
Domain entities
Controllers
Inertia + REST
Services
Business logic
Background jobs
Horizon queues
Vue files
82 pages · 179 components
LOC routes
6 route files
OAuth providers
Pluggable layer
Schema map
Central DB owns identity, billing and tenancy metadata. Each tenant DB owns its full domain.
Central DB
Identity · Billing · OAuth
Tenant DB
Per organisation · Isolated
Module map
How the 32 models cluster into bounded contexts. Each module owns its own services, jobs, and routes.
Path-based isolation, central users, cross-DB permissions.
Dual-layer subscriptions: platform Cashier + per-account billing.
Per-tenant + central OAuth configs + state manager.
Posts, stories, scripts, accounts — the content domain.
Time-series snapshots of accounts and posts for trend analysis.
Per-tenant settings, send log, queued delivery via Brevo.
Spatie MediaLibrary on S3 + comment threads on scripts.
Self-rescheduling fan-out — see the deep-dive →
01
Architecture · Isolation · Routing
Construida sobre stancl/tenancy 3.9 con identificación path-based: cada request resuelve el contexto de tenant antes del controlador, conmutando conexión de DB, cache, filesystem y cola.
El middleware InitializeTenancyByPath resuelve el tenant a partir del primer segmento de URL y conmuta la conexión activa de DB, cache y filesystem antes de que el controlador se ejecute. Todo el dominio funcional vive bajo /{tenant_id}/… sin colisionar con rutas centrales.
Cada organización obtiene su propia base de datos (tenant{id}) con 27 tablas migradas vía artisan tenants:migrate. La DB central mantiene únicamente 16 tablas de scope global: tenants, domains, usuarios, billing, OAuth configs.
Los usuarios viven en la DB central pero se referencian desde DBs de tenant mediante central_user_id como string — sin FK físicas. CentralUser::can() sobrescribe Spatie Permission para resolver siempre contra la conexión central, independiente del contexto activo.
Un middleware ClearPermissionCacheForTenancy purga la caché de permisos al entrar al contexto de tenant, eliminando el clásico bug de autorización cruzada que aparece al reutilizar workers entre tenants.
02
Dual-layer · Connected accounts
Dos flujos de dinero que conviven sobre la misma infraestructura — sin acoplarse, sin pisarse, y con reglas de acceso deterministas.
La plataforma cobra a cada tenant mediante laravel/cashier 15. El middleware CheckTenantSubscription intercepta cada request al namespace del tenant y bloquea acceso si no se cumplen tres invariantes: subscription ID válido, estado active/trialing, y current_period_end futuro.
Onboarding de cuentas conectadas por tenant para cobrar a sus propios clientes finales. StripeConnectService orquesta destination charges hacia la cuenta del merchant con split-payouts automáticos y application fee retenida en cada transacción. Webhooks reconcilian estado de cada cuenta conectada.
// access invariants — checked on every tenant request
public function isPaid(): bool
{
return $this->stripe_subscription_id
&& in_array($this->status, ['active', 'trialing'])
&& (!$this->current_period_end || $this->current_period_end->isFuture());
}03
6+ providers · pluggable
Un único OAuthService abstrae la lógica común; cada provider añade un controller especializado.
04
Tenant onboarding flow
Manager registers ┌──────────────────────┐
on /register ───▶ │ CentralUser created │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Tenant + Domain │ ◀─── tenants:create
│ central_subscription│
└──────────┬───────────┘
│ tenants:migrate
▼
┌──────────────────────┐
│ Tenant DB seeded │ 27 tables
│ permissions cleared │ ClearPermissionCache
└──────────┬───────────┘
│ first request
▼
┌──────────────────────┐
CheckTenantSubscr. │ isPaid()? ───── no │ ───▶ /billing
────────────────────▶│ │ │
│ yes │
│ ▼ │
│ Dashboard │
└──────────┬───────────┘
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
┌──────────┐ ┌────────────┐ ┌─────────────┐
│ Connect │ │ Connect │ │ Create │
│ social │ │ Stripe │ │ publication │
│ accounts │ │ account │ │ draft │
└──────────┘ └────────────┘ └─────────────┘05
External services orchestrated
06
Async · Deploy · Quality
07
Production dependencies — curated
Core
Tenancy
Payments
Async · Realtime
Integrations
Quality
End of case study