Multi-tenancy and limits

Logical tenant isolation

A multi-tenant system must ensure that one customer's data and activity never leak into another's. In the ub3r platform, every single database record is tagged with a tenant_id, and every query is strictly filtered by this ID. We enforce this isolation at the infrastructure layer using row-level security or dedicated repository wrappers. This "security by default" approach minimizes the risk of a developer forgetting a WHERE clause and exposing sensitive data.

Beyond data isolation, we also provide logical isolation for processing resources such as background workers and database connections. This prevents a single "noisy neighbor" from consuming all available capacity and slowing down the rest of the platform. We treat every tenant as a first-class citizen, ensuring that their experience is consistent regardless of who else is using the system. Multi-tenancy is not just a feature; it is a core architectural constraint that shapes every decision we make.

Resource scheduling

Fairness in a CPaaS means ensuring that a tenant sending a million-message campaign doesn't block another tenant's critical one-time password (OTP). The ub3r scheduler uses a weighted fair queuing algorithm to distribute connector throughput across all active tenants. This ensures that every customer gets a guaranteed slice of the pie, with the ability to "burst" into unused capacity when it is available. Transactional traffic is always given a higher priority lane to ensure sub-second delivery.

We also implement tenant-specific concurrency limits to prevent any single account from overwhelming our internal message bus. If a tenant exceeds their limit, we gracefully queue their messages and process them as capacity becomes available. This backpressure mechanism protects our system from spikes and provides a predictable performance profile for all users. Scheduling is the art of balancing individual demands with the collective health of the platform.

const scheduler = new PriorityScheduler();
// Ensure OTPs always go to the front of the line
scheduler.enqueue(message, { 
  priority: message.type === "otp" ? 10 : 1
});

Rate limiting and quotas

Rate limits are essential for protecting our API edge from both accidental abuse and malicious attacks. We implement limits at multiple levels, including per API key, per IP address, and per destination country. These limits are communicated clearly to our customers through standard HTTP headers like X-RateLimit-Limit and X-RateLimit-Remaining. Providing this visibility allows developers to build their own backoff logic and stay within their allocated quotas.

We also enforce spend caps and velocity checks to detect and prevent fraud, such as SMS pumping attacks. If a tenant's behavior deviates significantly from their historical pattern, our system can automatically trigger an alert or temporarily suspend their account. These safeguards protect both the ub3r platform and our customers from the financial impact of compromised credentials. Limits are a necessary part of a safe and sustainable communications ecosystem.