Behind the Counter: How Cosmo Works

If you missed Part 1, Scaling GraphQL Federation: Inside Cosmo’s Food Park sets the stage with the full analogy.

Now we’re stepping behind the counter with Cosmo to see what federation looks like in practice. What happens when menus change, special requests stack up, real-time updates come in, or a truck runs out of a key ingredient? Cosmo’s job is coordination, and this is how he accomplishes it.

The park isn’t open yet, but Cosmo’s already on his feet.

He walks the grounds with a clipboard, checking each truck’s menu. The burger truck swapped out the sourdough bun. The dessert truck added tiramisu. The coffee truck is testing a cold brew flight for the weekend.

Cosmo doesn’t make the food, but he needs to know what’s being offered and what changed overnight.

He starts with the shared menu board, a view built from what each truck contributes, agreed on ahead of time. That’s what customers see. It needs to be up-to-date, accurate, and complete. Not every truck has the same system, but they’ve all agreed to one format. If there’s a duplicate dish or a missing description, Cosmo spots and flags it before anything goes live.

Next, he loads the day’s configuration from the park office. That’s where the master plan lives. It tracks how orders are routed, who is responsible for what, and what to do if a truck goes offline. He doesn’t have to call the office every time he takes an order. The latest plan loads automatically, just in case anything has changed.

This is Cosmo’s prep work. He’s not guessing. He’s syncing with the system before the first customer even shows up.

The sun rises. The gates open. The first family walks in.

Time to get to work.

Cosmo doesn’t just take orders. He manages the menu.

Every truck runs its own kitchen. Some swap dishes weekly. Others tweak portion sizes or rename old favorites. One truck quietly added a plant-based option without telling anyone.

None of that chaos reaches the customer because Cosmo sees it first.

Each morning, every truck submits its updated menu. It's not a screenshot or a sticky note, but a structured list, written in a shared format so that Cosmo can combine them into a single, park-wide menu.

This is schema composition . Each menu is a subgraph . Cosmo merges them into a shared, composed supergraph.

He looks for conflicts: two trucks claiming the same dish name, mismatched prices, and missing descriptions. If the burger truck lists “Deluxe Combo” and the fry truck does too, Cosmo flags it. Someone has to pick a new name or at least agree on what it means. They decide together which one sticks.

No menu goes live until the checks pass. If something breaks, Cosmo sends it back.

From the customer’s point of view, the menu feels seamless. Behind the scenes, it’s stitched together from a dozen moving parts.

A group walks in: burgers, smoothies, fries, and desserts.

One person wants no pickles. Another wants oat milk. They place a single order and wait at the pickup window, just like any other day.

Cosmo doesn’t blink.

He splits the order into kitchen-specific slips. Burgers to one truck. Smoothies to another. Fries and dessert for two more, so nothing waits in the wrong line. He knows who handles what. He sends each slip with an awareness of what depends on what, so it all comes out together.

This is request routing.

Cosmo doesn’t make the food. He doesn’t guess who handles what. He has the map and uses it to resolve each part of the order to the right kitchen.

If the fry truck owns the sides field and the smoothie truck owns drinks, Cosmo sends each request to the right subgraph. No hardcoded logic. No spaghetti code behind the counter.

He waits for responses, assembles the tray, and calls the name when it’s ready.

It’s lunchtime. Orders are steady. Then the sushi truck runs out of fish, and the dessert truck loses power. No warning. Just a dark window and a missed pickup.

Cosmo doesn’t panic.

He sees the issue before the customer does. He steps out front, explains the delay, and offers a fallback. “No sushi today, but we can sub in a rice bowl. Dessert’s offline, but you won’t be charged.”

Cosmo doesn’t cancel the whole order just because one dish fails. He completes what he can, retries where it makes sense, and gives clear updates the moment something goes wrong. The rest of the order keeps moving.

Sometimes he reroutes the request—but only if the park’s rules allow it. If another truck offers a similar dish and fallback is configured, Cosmo can redirect the slip. Other times, he delivers a partial tray with a note: “We’re still working on the rest.”

He doesn’t leak internal chaos to the customer. Errors are masked or transformed so the experience stays smooth.

Behind the scenes, the routing rules follow a playbook. Cosmo doesn’t make decisions on instinct but follows a playbook, written to keep the park running even when things go sideways.

It’s not about avoiding every problem. It’s about handling them without breaking the whole flow.

It’s Saturday rush hour, and the park is packed.

Customers are ordering from five trucks at once, then pacing by the pickup counter, checking their phones. One leans over and asks, “Any update on my smoothie?”

Cosmo doesn’t yell across the park or go check the kitchen. Each truck pings him when an order hits the grill or is packed for pickup; he doesn’t need to ask because he is already listening.

Every truck sends him status updates in real-time, when the order starts, when it hits the grill, and when it’s ready for pickup. Cosmo relays that back to the customer without adding noise or slowing anyone down.

This is EDFS: Event-Driven Federated Subscriptions .

Each kitchen is wired into a shared pub/sub-system. Some use NATS, and others use Kafka, but Cosmo listens and transforms those into real-time updates, filtering them by order and delivering only what’s needed.

It’s all part of the same federation layer.

Subscriptions don’t require a separate system. Cosmo handles them using the same routing logic and composed supergraph schema.

So when someone asks, “How’s my smoothie?” Cosmo doesn’t need to check because he is getting updates in real-time as they happen.

Zoom out for a second.

Cosmo doesn’t just take orders. He is the system of coordination.

You didn’t orchestrate every move. You defined the rules and plugged him in.

You’re the park owner. Cosmo handles the traffic.

He makes sure the burger truck doesn’t overwrite the smoothie schema. He ensures that updates don’t break the shared menu. He enforces boundaries but still delivers a unified experience.

And he doesn’t do it alone.

Behind the scenes, Cosmo is backed by a comprehensive platform: Studio tracks changes and helps troubleshoot issues, the Control Plane manages updates, the CLI pushes and validates schemas, and routers run independently across environments—but all operate under the same rules.

Cosmo handles composition, routing, fallback, and subscriptions so you don’t have to build that system from scratch.

Your job is to run the park. Cosmo makes sure it works.

Even at rush hour, Cosmo keeps the park running smoothly.

Next: The health inspector arrives.

We’ll look at how Cosmo enforces schema contracts , prevents conflicting updates, and keeps the shared menu consistent before the gates open.

It’s the open-source federation layer we’ve built to coordinate schemas, route requests, and catch issues before they hit production.

If you’re juggling growing teams, shifting APIs, or changes that are hard to test before they go live, Cosmo can help .