Netflix is releasing La Bola Negra, the new film by los Javis, with the widest theatrical distribution in its history. The film had already won the best director award at Cannes, and the platform put up the money for distribution in the United States. Hipertextual covered it when the new trailer dropped: premiere in San Sebastián, release in Spain on September 25, and a United States release in October.

Why it matters

This isn't a film piece, it's a product case. Netflix built its entire identity on one thesis: theaters are an old channel, streaming replaces them. For years that thesis was practically religious inside the company. And here's that same company running the biggest theatrical rollout it has ever done.

The reading I care about is this: the platform didn't change its mind about its product, it changed its mind about what a secondary channel is for. The theatrical release isn't there to recover box office. It's there because there's a specific objective — awards season — that demands a requirement the main channel doesn't meet. The old channel didn't come back out of nostalgia: it came back because it's the only route to one particular outcome.

Anyone who has argued about architecture will recognize the pattern. You decided everything goes through the new API, that the legacy system gets switched off, that there are no exceptions. And then a requirement shows up — a client, an integration, a regulator — that can only be satisfied through the path you declared dead. The question isn't whether you betrayed your architecture. It's whether you had the requirement properly identified before you declared the death.

What changes in practice

What applies here isn't "go back to legacy." It's how you classify a delivery channel before deciding whether to shut it down. In my experience there are three kinds of channel, and confusing them is what makes migrations collapse halfway through.

Channel type What justifies it What happens if you shut it down
Primary Volume and product economics The business collapses
Enabling Unlocks an outcome no other channel reaches You lose the outcome, not the volume
Residual Inertia, habit, nobody reviewed it Nothing happens

Theaters, for Netflix, are an enabling channel. They don't move the business, they enable awards eligibility and the cultural conversation that comes with it. The typical mistake on a development team is treating every low-volume channel as residual, shutting it down, and finding out six months later that it was enabling something nobody had written down anywhere.

The concrete thing I do when this decision comes up: before retiring an old endpoint, a SOAP integration, a CSV export or an alternative login flow, I write down what outcome stops being possible if it disappears. Not how many users touch it — that metric lies, because an enabling channel always has low traffic — but what becomes impossible. If the answer is "nothing," I shut it down guilt-free. If the answer is "we lose the client that accounts for 30% of revenue," then we already know it wasn't residual.

The second practical change is in how you design the system while you still have both paths alive. An enabling channel almost never justifies a full parallel architecture. It justifies a thin adapter over the same core.

          ┌──────────────────┐
          │  Core (just once)│
          └────────┬─────────┘
                   │
        ┌──────────┴──────────┐
        │                     │
  ┌─────▼─────┐         ┌─────▼──────┐
  │  Primary  │         │  Enabling  │
  │  channel  │         │  channel   │
  └───────────┘         └────────────┘
     volume               eligibility

The rule I follow: if the secondary channel forces you to duplicate business rules, something is modeled wrong. The adapter translates format and protocol, it never decides.

When NOT to use it

This reasoning breaks down fast if you apply it by default. Three cases where keeping the old channel is the wrong call.

  • When the requirement is imagined, not verified. Netflix has a concrete, verifiable objective: awards eligibility. In a normal product, most "but some client needs it" claims don't survive a phone call. If you can't name the outcome and who cares about it, it's residual dressed up as enabling.
  • When you don't have the scale to pay for it. Netflix can fund a theatrical rollout without moving the needle. A team of five maintaining two delivery paths pays that cost on every release, every incident and every onboarding. The cost of an enabling channel isn't building it: it's that you can never again reason about the system by looking at a single path.
  • When the old channel contaminates the core. If keeping it forces you to preserve a data model that no longer describes the domain, the channel stopped being an adapter and became an anchor. At that point it's better to negotiate retiring the requirement than retiring the code.

An honest limit to this analysis: I don't know how the film will do, or whether Netflix's bet will pay off in awards. The available material describes the release and the cast, not results. I'm reading a decision, not an outcome. If the bet fails, it's still interesting as a case: an enabling channel can be correctly identified and still fall short of the objective.

What I'd do today

If you have an open migration, take the list of things marked as deprecated and classify each one into the three categories above. You'll find two surprises: things you've been maintaining for years with no outcome attached to them, and one or two you shut down — or are about to shut down — without knowing what they unlocked.

And keep the criterion handy for the next architecture discussion where somebody says "nobody uses that anymore." The right question isn't how much traffic it gets. It's what becomes impossible without it.