How Monkey Factory Uses WunderGraph Cosmo for Federated GraphQL and Event-Driven Subscriptions
TL;DR
Monkey Factory runs its mobility platform, bus, bike rental, and car sharing, on a lot of microservices and needed GraphQL Federation to give the frontend a single graph. Apollo Studio's pricing didn't work for them, and building real-time GraphQL subscriptions on Apollo was messy, even though subscriptions were core to an event-driven product. Monkey Factory moved to WunderGraph Cosmo and adopted Cosmo Streams (EDFS) to run event-driven federated subscriptions over NATS, including per-user subject targeting straight from an auth claim, with fast, hands-on support along the way.
State of GraphQL Federation 2026
How are teams governing schema changes, handling production traffic, and measuring Federation success? Share your experience and get early access to the full report. For every valid survey completed, we'll donate $30 to UNICEF .
Monkey Factory builds SaaS software for mobility: getting people from point A to point B without owning a car. Think bus, bike rental, and car sharing. Vincent Vermersch, the company's CTO, has worked on distributed systems since 2002.
Monkey Factory runs on a lot of microservices, and that architecture is what pushed the team toward Federated GraphQL.
At Monkey Factory, we needed Federated GraphQL because we use a lot of microservices, and for the front end it's so much easier. -Vincent Vermersch, CTO at Monkey Factory
With many services behind the product, Federation gave the frontend a single graph to talk to instead of a sprawl of endpoints.
Monkey Factory started on Apollo Studio, but two problems piled up. The first was cost: Apollo's new pricing didn't work for them. The second was subscriptions.
Building real-time subscriptions on Apollo was messy, and subscriptions weren't a nice-to-have for Monkey Factory. The team needed asynchronous patterns and event sourcing, which meant GraphQL subscriptions had to be first-class, not an afterthought.
Monkey Factory is moving off RabbitMQ toward NATS, and Cosmo's event-driven federated subscriptions (EDFS) fit that shift directly.
We have a huge need for asynchronous patterns and event sourcing, so GraphQL subscriptions were a must. Implementation of EDFS was easy because it was already plugged in. -Vincent Vermersch, CTO at Monkey Factory
One detail stood out to Vincent. Cosmo lets him use the user ID from a request's auth claim to target a NATS subject, so a subscription can plug straight into a specific user's messages. Combined with durable consumers, that lets the service wait for and gather a given user's messages reliably. Authentication was already in place, and the whole pattern was easy to express in the GraphQL schema.
Monkey Factory uses Cosmo for Federation today, but Vincent sees two more places for it.
The first is wrapping external GraphQL APIs. The team uses OpenTripPlanner for routing, and Vincent wants to put it behind Cosmo alongside the internal graph.
The second is fine-grained rate limiting. Not every query costs the same: asking "what's my name" is cheap, while planning a Bucharest to Paris trip is expensive. Vincent wants to weight and score CPU-intensive fields so the heavy operations are limited differently from the trivial ones.
The move off Apollo Studio was hands-on, and the WunderGraph team stayed close through it.
When we are talking on our Discord channel, they are there and they know what they are talking about. It's not first-level support where I wait a week for feedback. It really is a pleasure to work with WunderGraph. -Vincent Vermersch, CTO at Monkey Factory
Vincent's proof point was turnaround: he reports a possible bug one day and often has a fix the next. That kind of responsiveness matters when you're building on event-driven infrastructure.
Monkey Factory needed subscriptions that matched an event-driven, microservices world, and Apollo Studio wasn't giving them a clean path. Cosmo's EDFS over NATS did, with room to grow into rate limiting and external APIs next. To experience WunderGraph Cosmo, sign up for Cosmo's free tier and start building (no credit card needed)
If you prefer watching to reading, you can also view this case study as a video.
Frequently Asked Questions (FAQ)
Monkey Factory builds SaaS software for mobility, helping people get from point A to point B without owning a car. That includes bus, bike rental, and car sharing services.
Two reasons: cost and subscriptions. Apollo's pricing didn't fit Monkey Factory's needs, and building real-time GraphQL subscriptions on Apollo was difficult even though subscriptions were core to the product.
EDFS stands for event-driven federated subscriptions, part of Cosmo Streams. It lets the Cosmo Router connect directly to event systems like NATS, Kafka, or Redis so GraphQL subscriptions can run on real events instead of custom subscription infrastructure.
Cosmo lets Monkey Factory pull the user ID out of a request's auth claim and use it to target a specific NATS subject in a subscription. Combined with durable consumers, this lets a service wait for and collect a given user's messages reliably.
Monkey Factory plans to put its OpenTripPlanner routing API behind Cosmo alongside its internal graph, and to add fine-grained rate limiting that weights and scores CPU-intensive fields so expensive queries, like planning a Bucharest-to-Paris trip, are limited differently than cheap ones.
CCO & Co-Founder at WunderGraph
Stefan Avram is the CCO and one of the co-founders of WunderGraph, helping enterprise customers adopt and scale federated architecture. A former software engineer, he translates technical value into practical outcomes and shaped WunderGraph's early customer motion, guiding platform teams from onboarding to production in demanding environments. A former college soccer player, he brings a competitive, team-driven mindset to every stage of customer growth, with a focus on helping engineering-led organizations move fast without losing control.
