DEV Community: Bytephase Technologies Pvt Ltd

How a cached 301 put our homepage in a redirect loop (CloudFront + WordPress)

Bytephase Technologies Pvt Ltd — Mon, 05 Oct 2026 09:51:02 +0000

One morning our marketing site's homepage started failing with ERR_TOO_MANY_REDIRECTS. Every other page was fine. The cause turned out to be a perfectly reasonable cache setting meeting a perfectly reasonable SEO plugin. Here's the chain, because it's an easy one to walk into.

The two reasonable settings

1. The SEO plugin strips tracking parameters. Our WordPress site (bytephase.com) uses Yoast, which can 301-redirect /?fbclid=abc or /?utm_source=x to the clean URL /. That's good for duplicate-URL hygiene.

2. The CDN ignores tracking parameters in the cache key. In CloudFront we excluded utm_*, gclid, fbclid and msclkid from the cache policy. Otherwise every ad click creates a fresh cache entry and a cache miss. Also good.

How they combine

A visitor arrives at /?fbclid=abc.
CloudFront drops fbclid from the cache key, so the request maps to the cache entry for /. But the origin request policy still forwards fbclid to WordPress.
WordPress sees the parameter and answers 301 → /.
CloudFront caches that 301… under the key for /.
The next visitor requests /, gets the cached 301 → /, follows it, and gets the same 301. Loop.

The homepage was the only victim because it's where ad and social traffic lands.

The fix

The cache key and the origin request must agree on which parameters exist. If CloudFront ignores a parameter for caching, it must also not forward it to the origin.

We switched the origin request policy from "all viewer query strings" to all except the same list the cache policy excludes:

utm_source, utm_medium, utm_campaign, utm_term,
utm_content, utm_id, gclid, fbclid, msclkid

Now WordPress never sees fbclid, so it never issues the redirect, and nothing poisonous gets cached. Analytics still works, because GA reads the parameters client-side from the browser URL, not from the server.

Then we invalidated /*.

Two gotchas while verifying

Your browser caches 301s too. After the edge was fixed, Chrome kept looping from its own redirect cache. Test with a fresh profile, or fetch(url, {cache: 'reload'}), before declaring it still broken.
The loop can return quietly. Add a parameter to the cache-key exclusions later without adding it to the origin exclusions, and the same chain re-forms. We now keep the two lists side by side in the same change.

Takeaway

Any time a CDN normalises a request (drops parameters, headers or cookies from the cache key), ask: can the origin answer differently based on the thing I just dropped? If yes, either keep it in the key or stop forwarding it. Redirects are the worst case, because they're cacheable and they point at themselves.

We build repair shop management software at BytePhase. The marketing site is WordPress behind CloudFront, and we write up the infrastructure lessons here as we hit them.

Database-per-tenant in Laravel: 6 lessons from running a multi-tenant SaaS

Bytephase Technologies Pvt Ltd — Mon, 05 Oct 2026 09:50:52 +0000

We build BytePhase, repair shop management software used by 2,000+ repair businesses in 32+ countries. Every customer account gets its own database. Here's what that choice taught us. None of it is exotic, but most of it we learned the hard way.

The setup

Laravel + stancl/tenancy, database-per-tenant mode.
One central database holds tenant metadata, subscriptions and plans.
Each tenant gets a tenant_{id} database with ~120 tables: tickets, invoices, inventory, customers and so on.
Tenants are identified by subdomain.

The pitch for database-per-tenant is isolation: a missing WHERE tenant_id = ? can't leak one shop's customers into another shop's screen, because the other shop's rows aren't in the database at all. That holds. The cost moves elsewhere.

1. Queued jobs have no tenant until you give them one

An HTTP request finds its tenant from the subdomain. A queued job doesn't: by the time a worker picks it up, there's no request at all. The rule we now enforce everywhere:

public function handle(): void
{
    tenancy()->initialize($this->tenantId);
    // ... the actual work
}

Pass the tenant id into the job's constructor, initialise tenancy first in handle(), and never rely on "whatever tenant was active when this was dispatched". Without this, a job can run against the wrong database, or the central one, and nothing tells you.

2. Cache keys are shared unless you make them not

Redis doesn't know about your tenants. Cache::remember('settings', ...) in tenant A, then the same key in tenant B, and B sees A's settings. stancl/tenancy can prefix cache tags per tenant, but any hand-rolled key (rate limiters, locks, Cache::forever calls in a service class) has to include the tenant id. We treat a cache key without a tenant prefix as a bug in code review.

3. "Tenant" is not always "business"

Our customers asked for something database-per-tenant doesn't give you for free: several billing identities inside one account. One owner might run two shops with different tax numbers, logos, invoice number series and bank details, while sharing staff and customers.

So inside each tenant there's a second level, a business:

The frontend sends an X-Business header.
Middleware resolves it to the current business.
A global Eloquent scope filters business-owned models (invoices, stock, jobs).
business_id is stamped on create and can never change.
Documents always print with their own business's identity and numbering, never the one in the current header.

Lesson: decide early which tables are tenant-wide (customers, staff, masters) and which are per-business, and write it down. Retrofitting the scope later meant touching every query that assumed "one shop per database".

4. Migrations run N times, so they must be boring

A migration that takes 2 seconds takes 2 seconds × every tenant. Worse, one tenant with odd data can fail halfway through a batch. What works for us:

Schema migrations only. Settings and data rows go through idempotent seeders, never data migrations.
Never edit a migration that has already run anywhere.
Every migration must be safe to re-run on a tenant where it half-applied.

5. Per-tenant settings need defaults that can roll forward

New settings keys land in a definitions class with defaults. A seeder ensure()s them on every existing tenant/business. Code always reads through a helper that falls back to the default. That way a new feature never crashes on an old tenant that hasn't been backfilled yet.

6. Isolation is a property you test, not one you assume

Database-per-tenant makes cross-tenant leaks rarer, not impossible. Shared caches, shared queues, file storage paths, and anything that touches the central connection are all ways back in. We keep a short checklist for every feature:

Does it run in a queue? → initialise tenancy.
Does it cache? → tenant-prefixed key.
Does it store files? → tenant-scoped path.
Is it business-scoped? → global scope + immutable business_id.

If you're building something similar, or you run a repair shop and want to see where all this ends up, the repair ticket workflow is the part of the product every one of those lessons touched. Happy to answer questions in the comments.