Architecture & Projects · Vinnicius Santos — Architecture decisions in multi-tenant SaaS

Architecture & Projects · Vinnicius Santos — Architecture decisions in multi-tenant SaaSCase studies by Vinnicius Santos: architecture, security, and deployment decisions in multi-tenant SaaS built with C#/.NET, Next.js, and PostgreSQL, with the trade-offs behind each choice.To me, architecture is the set of decisions that become expensive to change later. So for each project I record what I chose, why I chose it, and what I left out, including the technical debt I took on deliberately.PendurAi — Multi-tenant POS and ERP SaaS for wine shops and small marketsA point-of-sale and back-office system sold to multiple stores, with recurring billing per store.

Single schema with tenant_id isolation. All stores share one schema, and the tenant is applied to every query through a tenant provider. It lowers cost and simplifies operations; in exchange, isolation depends on application discipline.

Dapper and Npgsql on the transactional path. A sale writes inventory, sale, and ledger in one atomic transaction, so I chose direct control over SQL and transactions. The Supabase REST client is limited to authentication.

Immutable ledger and blind cash count. Cash drops and top-ups only enter as new entries, and the operator counts the drawer without seeing the expected balance. Shortages surface on their own, without relying on trust.

Webhooks behind a durable queue. Delivery orders enter a queue and are processed by a background service, with HMAC signatures and rate limiting. A spike or failure neither takes the POS down nor loses an order.

Licensing driven by payment. The payment provider webhook updates the license status, and login is blocked when it is suspended, canceled, or expired.

MarcAi — Scheduling SaaS platform for beauty salonsOne application serves many salons, each with its own subdomain, team, schedule, and finances.

Tenant resolved from the subdomain. A middleware resolves the salon from the URL and caches the result for 60 seconds. The session cookie is host-scoped and carries the tenant, checked against the URL on every request.

Scheduling conflicts blocked in the database. A PostgreSQL EXCLUDE constraint prevents overlapping appointments, and a trigger enforces the cancellation rule. The C# validation exists, but it is not the last line of defense.

TOTP 2FA implemented from scratch. The RFC 6238 algorithm was written without an external package and validated against the official RFC test vectors, to understand and test what protects the super admin panel.

Wildcard TLS through the DNS-01 challenge. Since each salon has a subdomain, the certificate must be a wildcard, which the HTTP-01 challenge does not cover. Caddy issues the certificate through DNS.

IT Governance Portal — Internal system for access, hardware, telephony, and knowledgeCentralizes access requests, inventory, company phone lines, and policies that used to live in spreadsheets.

The application is the only database client. The first version used Row Level Security on Supabase. I migrated to a dedicated Postgres, with authorization made explicit in code on every read and write, to avoid depending on a third-party platform.

Defense in depth with triggers. Fields that are immutable after creation, blocked self-escalation of privilege, and a mandatory reason on every rejection are enforced by the database.

Audit trail written only by triggers. Every relevant write produces a log entry through a trigger, and no application code writes to the trail directly.

Own, revocable sessions. An opaque token in an HttpOnly, Secure, SameSite=Strict cookie, validated against a sessions table. Deactivating an account cuts access immediately.

Mocidade 015 — Bus seat reservations for group tripsParticipants pick a bus by departure terminal and choose a seat on a map, with a waitlist.

Reservations in Serializable transactions. Reserving, canceling, and assigning seats run at the highest isolation level, which prevents two participants from getting the same seat.

Secrets kept out of the repository. The connection string never sits in the configuration file: it comes from an environment variable or user secrets.

Automatic deployment on every push. GitHub Actions publishes the app, ships the files via rsync, and restarts the systemd service. A Dockerfile covers running it in a container.

Life OS — Personal dashboard for routine, workouts, nutrition, and studiesA daily-use tool with individual accounts and architecture documentation versioned alongside the code.

Decisions recorded as ADRs. Stack choice, authentication model, and build strategy are captured as Architecture Decision Records in the repository.

Builds happen off the server. The Docker image is built on GitHub Actions rather than on the EC2 instance, so builds do not compete for memory and CPU with production apps.

Per-user Row Level Security. Data is isolated by Postgres policies, and the marketing site is the only public part.

Agenda Osvair — Online booking for an executive transport serviceThe customer requests a time slot, receives a quote, and approves it before the ride enters the schedule.

No application server. The static front end talks directly to Supabase, protected by RLS. Deployment is a file copy, and operating cost is minimal.

Business rules in database functions. With no backend of its own, the rules live in Postgres RPC functions rather than in the browser.

WhatsApp through a universal link. The quote goes out through a wa.me link, with no messaging API cost.

Architecture and projects

About

Tools

GitHub