Identity and sessions
Registration with verification, login, refresh, MFA, Google OAuth and per-device sessions. Rate limits and live revocation.
Lab
The platform where I test real architecture
The distributed services hub: a core that solves the common ground —identity, subscriptions, payments and support— and independent tools that plug into it.
ARCHITECTURE
Central authentication, simple services
The core concentrates authentication: it signs the credentials and each service verifies them on its own, using the same standard Google and Microsoft use to connect their services. Users sign in once, security is hardened in a single place, and a new API starts without rebuilding the login.
CORE MODULES
What the core solves
Six modules the core already brings: identity, money, background jobs, notifications, the user panel and security.
Wallet and payments
An immutable ledger per user: tools move money through the reserve/settle/credit saga, without ever writing to the database.
Background jobs
Async queues that scale horizontally with replicas, with retries, DLQ and signed webhooks.
Notifications
Email, SMS, WhatsApp and web push, with a newsletter, campaigns and in-app notices: per-channel, per-language templates to edit the wording.
User panel
Profile, wallet, purchases, payments, sessions and notices in one panel inside the core: tools reuse its components instead of each building their own.
Sentinel
An isolated central security system that aggregates telemetry, detects distributed attacks and propagates the denylist, with behavior analysis and risk scoring.
PIECES
What each decision implies
Four decisions hold the system up, and each one leaves a concrete consequence once there is more than one product in play.
The common ground is fixed once
A change in the core —the login, a security rule, a payment— ships once and serves every product.
Adding a tool doesn't touch the others
A new tool is one more folder —app, API client and its own API—: it ships on its own, without touching the core or the ones already running.
Data never mixes
Each service has its own database and cache: a schema change or a delete stays on its side and never reaches the others.
One recipe for all of them
The three layers —app, API client and serverless API— are the same everywhere: building the next tool means copying the structure, not deciding it again.
TEAMS WITH A SCHEDULE
Online booking SaaS
The platform booking SaaS: each team publishes its own site with its own slug, its services and its calendar, and anyone can book without creating an account. The professional calendar syncs both ways —a commitment they already had elsewhere blocks the slot here— and their agenda is a single one across every team they belong to: two bookings never collide, not even across teams.
The journey of a request
- The team siteEach team publishes its landing page on its own slug and assembles it section by section; the team plan decides how many members fit and which site variants are unlocked.
- Service, day and timeThe visitor picks a service, a professional and a day; the calendar only offers free slots and the hold stands while they finish.
- The bookingThe API writes the booking against a unique index per professional and slot: two requests for the same time never overwrite each other, not even in a race, and the same professional is never in two places even across teams.
- The shared calendarThe booking lands in the platform Calendar API: each tool writes its own layer and the whole calendar of the user is composed at read time, with only what each member may see. A professional busy in another tool shows up as busy here.
- The round trip with GoogleThe Calendar API is the only piece that talks to Google Calendar, and it syncs both ways: a commitment the professional already had blocks the slot on the site, and the confirmed booking shows up in their calendar.
- The reminderThe core schedules the task 24 hours ahead and comes back with a signed request: the reminder goes out without the tool keeping a process waiting.
- The staff confirmsThe person on the desk logs in with their core account and their team role, confirms the booking and sees it on the agenda calendar.
- Outside the requestThe booking is already confirmed: telemetry and the security event leave in the background and the central sentinel cross-checks them with the rest of the platform.
Its own serverless API, database and cache: from the core it takes identity, the reminder task and the sentinel, and the calendar does not live here —every mutation is published to the platform Calendar API, which is the one that syncs with Google—.
MAINTENANCE COMPANIES
Elevator maintenance system
The system for companies that maintain elevators: consortia, buildings and units with their technical record, visits the technician closes from the phone —the report replaces the WhatsApp group— and maintenance that comes back month after month without anyone entering it again. Roles are built permission by permission, and the plan sets how many buildings, elevators, members and recurrences fit.
The journey of a request
- The technician, on siteOpens the app from the phone with their core account: the API verifies the token against the JWKS, without asking the core on every request.
- The unit's sheetConsortium, building and elevator, with its technical sheet and its history: the visit starts knowing what was done last time.
- The visit and the reportThe technician logs what was done and attaches the report from the spot; it stays in the unit's history and in the month it belongs to.
- The month that comes backMaintenance repeats month after month: the core wakes the task and comes back to the tool with the signature, so nobody has to remember.
- The consortium looksThe administration logs in with its own role and sees the buildings, the units and what is coming due: permissions belong to the tool, not the core, and the plan sets how many buildings, elevators, members and recurrences fit.
- Outside the requestWhat must not cost the technician a second leaves in the background: rejections and security events go to the central sentinel, which cross-checks them with the rest of the platform.
It runs with its own database and cache: from the core it takes identity, the clock that wakes the monthly recurrences and the sentinel.
DATA TEAMS
Dashboards on your own sheet
The analysis service: the user connects their Google Sheets spreadsheet and builds dashboards and reports on top of it —the data is neither migrated nor mirrored: the math runs live and only the configuration is kept—. The token for that connection is encrypted with AES-256-GCM and never leaves again, and the sheet provider sits behind a port, so adding Excel does not touch the contract.
The journey of a request
- The sessionThe user logs in with their core account and the API verifies the token on the spot against the JWKS: no identity call per request.
- The connected sheetGoogle Sheets or Excel goes in through OAuth; the sheet is not migrated nor mirrored, it is read where it lives.
- The encrypted tokenThat connection's token stays encrypted (AES-256-GCM) and never leaves again: without the encryption key, the API fails closed.
- The dashboardCharts and tables over the sheet; what gets stored is the dashboard configuration, not a copy of the data.
- The math on the flyWhen the dashboard opens, the API asks for the sheet again and aggregates right then: the number on screen is today's number.
- Outside the requestTelemetry and security events leave in the background for the central sentinel to cross-check; the analysis does not wait for them.
Of the core's six modules it uses two: identity for the session and the sentinel for the events. Everything else —the sheet, the encrypted token and the dashboards— is its own.
Want to see it in action?
The code isn't public yet, but I can walk you through it: ask for a demo and I'll show you the core, the tools, the wallet saga and the sentinel from the inside.
Request a demo →