Decoupling commerce and content: Medusa.js, Payload CMS and Meilisearch for Yogateria

The problem with one system doing everything

A single monolithic commerce platform tends to force a bad compromise: the commerce engine's content editor is usually rigid, and a general-purpose CMS is usually a poor fit for cart/checkout logic. Yogateria needed both a flexible marketing/editorial workflow and a serious commerce engine with wholesale pricing tiers, so we split them into three cooperating services instead of picking one tool and stretching it.

Where each piece actually earns its place

Medusa.js owns commerce state: cart, checkout, orders, and the custom pricing engine that supports both B2B wholesale tiers and standard B2C pricing. Payload CMS owns editorial content: landing pages, promotional copy, and anything a non-engineer needs to edit without a deploy. Meilisearch owns product discovery: it maintains its own denormalized index of product data, updated via webhooks whenever Medusa's catalog changes, so search stays fast without querying the commerce database directly for every keystroke.

Keeping three services in sync without a shared database

The hard part of this architecture is not any one service — it is keeping them consistent without letting them share a database, which would defeat the point of decoupling them. Catalog updates in Medusa fire webhooks that Meilisearch consumes to reindex only the changed products, rather than a full reindex, which keeps search freshness close to real-time even on a large catalog.

What the split actually bought us

Search stays fast under load because Meilisearch never touches the transactional database. The Next.js frontend uses the App Router with React Server Components and ISR, so most pages are served from cache and only revalidate when their underlying content or catalog data actually changes. That combination does most of the performance work, with no bespoke tuning on the frontend itself.

The honest trade-off

Three services means three things that can be down instead of one, and eventual consistency between Medusa and the search index means there is a small window (seconds, not minutes) where a just-updated product might show stale data in search results. For Yogateria's traffic pattern that trade-off was clearly worth it; for a much smaller catalog with infrequent updates, a single Medusa + Next.js setup without the extra search layer would probably be the simpler and equally correct choice.