Beta
Quick Q&A on why we’re sticking with a modular monolith and when it might make sense to split (hint: not now).
See Architecture assessment for the overall scorecard.
Should we split Supabase + Convex into separate services?
Answer: No — use modular monolith with adapters.
Shared data model and small team. Dual-write plan + feature flags already handle progressive backends without extra deployments.
Owner: Infra + Product
Watch: If Supabase usage or Convex compute cost spikes independently.
When would a service extract make sense?
Answer: Only if a domain exceeds team capacity (e.g., translation SaaS with separate team).
Service extraction requires dedicated team, independent scaling, separate SLAs. Not true today.
Owner: Leadership
Watch: New dedicated team + roadmap pushes for autonomy
How do we isolate domains without microservices?
Answer: Use namespace layering (domain/application/infrastructure/presentation) and event-driven boundaries.
Keeps code modular while sharing deployment + database.
Owner: Engineering
Watch: Namespace drift or cross-boundary imports
What about grid composer / AI pipelines?
Answer: Treat as features inside existing app; use edge functions for heavy workloads.
Serverless functions provide isolation without microservice overhead.
Owner: AI/Studios pod
Watch: Sustained workloads > 2 minutes or dedicated scaling needs
Only consider extraction when one of these trips. Otherwise we keep investing in namespaces, events, and adapters.
| Domain | Trigger | Action |
|---|---|---|
| Translation Studio | Separate revenue stream + dedicated team | Extract read-heavy APIs into service with its own DB snapshot |
| AI pipelines | Jobs routinely exceed serverless limits | Move to worker queue (Supabase functions or dedicated worker) |
| Learning cohorts | Need for custom compliance / data residency | Spin up region-specific instance, still sharing schema |