Skip to content
➜cat gealo/scale.md
DEPLOYED ·gealo.app
cd ../gealo
TIER_04

Scale

This is not a request-volume brag. The five things Gealo is engineered against, with the problem on one side and the approach on the other. Operational numbers stay internal.

[01]CACHE

Tenant-scoped cache keys

PROBLEM

A single shared cache leaks across tenants if any code path forgets the tenant filter. The blast radius of one bad call is everyone.

APPROACH

Every cache key carries a tenant prefix as a structural rule, not a convention. Invalidation events scope to the tenant. Cross-tenant cache reads are inconvenient to write and obvious in review.

[02]JOBS

Queue isolation per tenant

PROBLEM

Noisy-neighbor jobs (an enterprise tenant importing 10k rows) starve quiet tenants who just want a leave approval to land. Shared queues without isolation guarantee occasional outages for the smallest customers.

APPROACH

Tenant-aware queue service runs work inside tenant lanes with distributed locks. Loud tenants spend their own slice of throughput. Quiet tenants get predictable latency.

[03]AUDIT

Soft delete with audit trail

PROBLEM

Hard delete is fast but unrecoverable. Real teams need a restore window and an answer to "who deleted this and when". A pure hard-delete model also fights compliance.

APPROACH

Resources soft-delete by default with a retention window from tenant policy. Audit log captures who, what, when, and from where. Restore is an action, not a support ticket. Hard delete is an explicit lifecycle event.

[04]LIMITS

Plan-aware throttling

PROBLEM

A single global rate limit is unfair to enterprise tenants and too generous for the free tier. Per-user limits miss the abuse vector of "one tenant runs a hundred users on automated jobs".

APPROACH

Multi-level rate limiting reads from the entitlements service. Free, pro, and enterprise see different envelopes. The specific concurrency, burst, and refill numbers stay internal. The public part is that throttling decisions ride the same single-source-of-truth as feature caps.

[05]TELEMETRY

Observability with tenant context

PROBLEM

A bug report from one tenant requires walking logs that mix every tenant's traffic. Without per-tenant context, root cause analysis is a grep festival.

APPROACH

Structured logs include tenant id, user id, project id, request id on every line. PII and secrets are never logged. Metrics dimension on tenant so noisy tenants are immediately visible. Pager wakes only for tenant-scoped issues that warrant pages.

➜// withheld on purpose

Concurrency numbers, queue depths, JWT TTLs, exact rate-limit envelopes, and SLO thresholds stay internal. Those are operational details that change with infrastructure. What stays stable is the single-source-of-truth rule that all of them resolve through. That is the engineering claim.