Engineering · Architecture

How our systems are actually built.

Most agencies show screenshots; here are the diagrams. These are the reference architectures behind the products in our portfolio - drawn plainly, explained honestly, including the trade-offs.

1 · The production platform

Every Mokshify product starts from this shape. Nginx terminates TLS and routes; Node.js or Python/FastAPI services own bounded domains; PostgreSQL is the source of truth and Redis the hot path. Workloads are containerised and provisioned by Terraform, so any of the four clouds can run them. The trade-off is deliberate boredom: fewer moving parts, well understood, cheap to operate - novelty budget is spent on the product, not the plumbing.

2 · The deployment pipeline

The sequence shown in our homepage film’s terminal is this pipeline: every merge runs the test suite and static checks, then an AI review pass reads the change for what tired humans miss, then a staged rollout ships behind health checks with one-command rollback. Nothing reaches production by hand. This is why we can publish an uptime figure (99.98%) without flinching.

3 · The RAG pipeline

Retrieval-Augmented Generation as we ship it: documents are chunked and embedded into pgvector (inside the same PostgreSQL that runs the product - one database to operate, not two), queries retrieve the relevant passages, and the model answers from them with citations. The unglamorous part is the evaluation suite: a scored test set of real questions that runs before every release. Details on the AI service page.

4 · Multi-tenant data design

SaaS tenancy is decided at the data layer on day one. Our default is row-level tenancy: every table carries a tenant key, enforced by PostgreSQL row-level security and query-layer guards, with connection pooling shared across tenants. Schema-per-tenant is reserved for cases that genuinely need it (regulatory isolation, per-tenant customisation) because its migration cost compounds. Billing, quotas and metering hang off the same tenant spine - which is why pricing changes stay configuration, not surgery. The full reasoning lives on the SaaS page.

5 · Security layers

Defence in layers, each assuming the one before it failed: TLS and rate limiting at the edge; authentication, security headers and request shaping at the gateway; authorization and input validation inside every service (never trusting the gateway alone); encryption at rest, least-privilege database roles and audit trails at the data layer. Secrets live in managed vaults, never in code - the same standards listed on our process page, applied to this website too.

Related: Technology stack · Process & standards · Cloud Engineering · Client work