Micro Kafka Shop

Problem

An e-commerce platform with products, orders, and payments sounds like a weekend project until you realize that if you want to really scale that tight coupling between those pieces creates fragility. A payment service outage shouldn’t take down the catalog, and an order shouldn’t depend on a synchronous call to a checkout API that might be slow or down. The challenge was to build three independent services that stay consistent through events rather than shared databases or direct HTTP calls.

Solution

• Designed three backend services with different frameworks to mimic a real use case: Express for the product catalog, Fastify for order management, and Hono for the payment layer. Each owns its own database — PostgreSQL for products via Prisma, MongoDB for orders via Mongoose — so they can evolve independently.
• Introduced Apache Kafka as the event bus. When a product is created, the product service emits product.created; the payment service consumes it and creates a matching Stripe product. A successful checkout emits payment.successful; the order service consumes it and persists the order. No service calls another directly.
• Built a shared Kafka wrapper package with configurable timeouts, heartbeat defaults, and safe session handling, so every producer and consumer across the monorepo shares the same connection logic without duplicating it.
• Created two Next.js storefronts — a customer shop and an admin dashboard — sharing a UI library, type definitions, and Zod schemas. Clerk handles authentication and role-based access on every service endpoint, with user/admin roles enforced server-side through middleware.
• Integrated Stripe Checkout with embedded Elements and webhooks: the payment service builds line items from the cart, returns a client secret, and listens for checkout.session.completed to emit events downstream.

Result

• Services deploy and scale independently — the order service can go down without affecting product browsing or admin operations, and vice versa.
• Adding a new service (notifications, analytics, recommendations) means subscribing to existing Kafka topics, not touching any producer code.
• The Turborepo monorepo with shared types caught cross-service contract mismatches at build time, not in production.