GRAMA

Hexagonal architecture and DDD with 12 bounded contexts

Courses, progress, assessments, analytics, AI and tenancy each change for different reasons. Modelling them as bounded contexts inside a modular monolith keeps the domain logic independent from Next.js and Supabase behind ports and adapters, so each context can be tested and evolved on its own without paying the operational cost of microservices.

Multi-tenancy enforced by Row Level Security, not only by application code

With several institutions and roles sharing one database, a single missing WHERE clause would leak data across tenants. Row Level Security policies make PostgreSQL itself reject rows outside the caller’s institution and role, and every server action still re-derives the role from the session instead of trusting client claims. The schema was sized for 30,000 users and 8,000 concurrent peaks and validated with k6 load tests.

pgvector in the same Postgres instance for the RAG assistant

A dedicated vector database would have meant another service to provision, secure and pay for. Embeddings are always queried together with relational data such as enrollment and tenant, so keeping them in Postgres lets the assistant join similarity search with permission checks in one query, under the same RLS policies.

Analytics on PostgreSQL aggregates and RPCs

Institution dashboards aggregate completion and progression data across many users. Computing those aggregates inside the database and exposing them through RPCs avoids shipping raw rows to the server and keeps the heavy queries close to the data, behind the same access rules as the rest of the platform.

Server Components for reads, client state only where it adds value

Rendering pages with data already fetched on the server avoids loading waterfalls, so teachers see a populated page immediately. Client-side state is reserved for interactive flows such as quiz submissions, progress updates and the streaming assistant.