Building a Multi-Tenant Architecture Platform to Scale the Emmys

Jun, 24 2025

In a previous post, we shared how Crowd Favorite helped the National Academy of Television Arts & Sciences (NATAS) handle a massive 570% spike in users for their Emmy Award competitions, thanks to their custom Laravel-built platform, Orthicon.

Today, we're going under the hood to look at the tech that powers it. Specifically, we'll see how the Crowd Favorite developers used Laravel to build Orthicon’s multi-tenant architecture, which supports dozens of distinct Emmy regional competitions from a single, robust codebase.

Why Multi-Tenancy?

A multi-tenant architecture allows a single application instance to serve multiple distinct groups of users (or "tenants") while keeping their data, configurations, and user experiences logically isolated and secure.

This was the challenge NATAS faced. They don’t just run a single Emmy Awards competition. They oversee numerous regional chapters, each hosting its own competition with unique users, judges, submission deadlines, specific rules, and even branding. Traditionally, this would require juggling numerous isolated application instances, a scenario fraught with management overhead, inconsistent feature rollouts, and duplicated effort. 

Crowd Favorite knew a smarter, more scalable approach was essential. NATAS needed to run multiple Emmy competitions (or tenants, and often simultaneously) without the headache of provisioning and maintaining separate applications for each. 

The answer? They developed Orthicon on a thoughtfully designed multi-tenant architecture built on Laravel.

Why Multi-Tenancy With Laravel?

Laravel delivered the tools the Crowd Favorite devs needed:

With these features, they could use Laravel's inherent strengths to build a system that was both powerful and easy to develop.

How Crowd Favorite Orchestrated Multi-Tenancy in Orthicon

The Crowd Favorite team played to Laravel’s core strengths to build a multi-tenant architecture for the Orthicon platform. Here’s how they made it work:

Tenant Identification: The Lightweight Token Approach

Crowd Favorite designed the Orthicon application with lightweight multi-tenancy in mind. Each incoming request is efficiently associated with its respective tenant (competition) using a unique token, typically passed via a custom HTTP header. Custom Laravel middleware, processed early in the request lifecycle, is responsible for inspecting this header, identifying the correct tenant based on the token, and retrieving its specific configuration. 

Once this tenant object is resolved, it's elegantly bound into Laravel's service container as a singleton instance. This crucial step makes the currentTenant context globally accessible throughout the duration of that request within Orthicon, yet remains neatly encapsulated and managed by the framework.

Data Isolation: Using Eloquent Global Scopes

With the tenant identified and available in the container, ensuring strict data separation within Orthicon was paramount. Crowd Favorite masterfully employed Eloquent global scopes. They defined a specific TenantScope class. This scope is then applied to all relevant Eloquent models with tenant-specific data. 

Internally, the apply method of this scope checks for the presence of the currentTenant from the service container. If a tenant is identified, the scope automatically modifies any outgoing database query for that model by adding a WHERE tenant_id = ? clause, dynamically inserting the current tenant's ID. 

This elegant solution, built into the ORM layer, ensures that each competition only ever interacts with its own dataset within Orthicon, without developers needing to add tenant conditions to every query manually. This allowed Crowd Favorite to use a single database with a tenant_id column on relevant tables, avoiding the complexities of managing separate databases per tenant. 

For reporting needs, data across tenants can still be aggregated by programmatically disabling or bypassing the global scope when necessary.

Dynamic Configuration and Tenant-Specific Services

Many aspects of each competition managed by Orthicon needed to be unique: time zones, S3 storage buckets for submissions, custom navigation menus, localized notifications, translations, and even billing details.

Crowd Favorite leveraged Laravel's service providers and their dynamic configuration capabilities. Once the currentTenant was resolved, service providers could programmatically set tenant-specific configuration values at runtime (for example, updating the target S3 bucket for file uploads). 

They could also conditionally bind different implementations of services based on the tenant, or load tenant-specific language files and view composers. This ensured that core Laravel systems like file storage (Flysystem), notifications, and localization operated seamlessly within the active tenant's context in the Orthicon platform.

Tenant-Aware Caching and Queues

Performance and background processing also demanded tenant awareness within Orthicon.

  1. Caching: Laravel's cache was configured to use tenant-specific prefixes or tags. This clever strategy allowed Crowd Favorite to clear the cache for one competition (for instance, by flushing all cache entries tagged with a specific tenant's ID) without impacting the performance or data integrity of other concurrently active tenants.
  2. Queues: Background jobs, crucial for tasks like processing large numbers of entries or generating reports, were designed to carry tenant context. Typically, the tenant_id would be passed to the job when dispatched. When the job is processed by a queue worker, often in a separate process, the job would re-resolve or re-bind the tenant context based on this stored ID, ensuring all operations within the job run against the correct tenant's data and configuration.

Granular Authorization: Tenant-Level Roles and Permissions

Each regional competition needed full control over its user roles and access levels within Orthicon. Crowd Favorite utilized Laravel's authorization layer (gates and policies) to define permissions that were intrinsically scoped to the current tenant. This provided fine-grained control without a complex global roles system, empowering each competition to manage its own team effectively and independently.

Decoupled Multi-Tenancy Core

Crowd Favorite’s key architectural choice for Orthicon was implementing multi-tenancy as an abstract, decoupled core module. This layer handles tenant identification, data scoping, and context switching, remaining completely independent of the application's domain logic (the specific features for managing Emmy competitions).

This separation is common in well-structured Laravel apps and makes the code easier to reuse and maintain. The core multi-tenancy logic doesn't intertwine with business features, making the entire Orthicon system cleaner and easier to evolve.

Multi-Tenancy Benefits: Agility and Focus 

Crowd Favorite’s developers built this Laravel application thoughtfully so that NATAS could achieve the following goals:

What’s Next: Building on Orthicon's Foundation

With Laravel as the bedrock of the scalable Orthicon multi-tenant platform, Crowd Favorite and NATAS have ample headroom for future innovation. They are already exploring enhancements for Orthicon, like advanced handling and processing of entry videos, AI-assisted judging tools, and real-time dashboards for competition administrators. Thanks to the flexible architecture, these new features can be developed and rolled out efficiently across all competitions.

Crowd Favorite's work on the Orthicon platform is a powerful demonstration of how to use Laravel to build sophisticated, scalable, and maintainable solutions for complex business needs. It's not just about writing code; it's about architecting systems that empower users and grow with their ambitions. 

Check out Laravel docs and start building.

By Ana Tavares

I am who I'm meant to be, this is me.

Follow the RSS Feed.