For large systems

Start with one project. Split it into services when you grow.

Most products run fine as one project. When you have several teams, heavy traffic or parts that must scale on their own, split them into microservices that talk through signed calls and Kafka events. Same platform, same prompts, nothing to rewrite.

KAFKAKafka & microservicesOne event reaches every project.

Signed calls, Kafka events and one sign-in between projects

?What is Kafka & microservices?

When you have several teams, heavy traffic or parts that must scale on their own, split them into microservices that talk through signed calls and Kafka events. Same platform, same prompts, nothing to rewrite.

?What is it for?
  • Outbox: if the save fails, nothing leaves
  • Duplicates skipped, failures retried
  • Optional: off by default, on when you grow
How does it run?
Why is it better?
Usually

Hand-written webhooks with no signature, retry or idempotency; a message broker to wire yourself.

With Vybev

Publish with one line of code. Listen by adding a Kafka item with a topic and an event.

kafka.block✓ shop.orders · order.paid published once✓ CRM, accounting, warehouse react✓ Failed 5 times → dead-letter topic
  • The order and one outbox row are written in the same transaction → if the save fails, nothing leaves
  • Every event carries an idempotency key → a duplicate returns the first result, never charged or shipped twice
  • The Kafka controller routes, skips duplicates, retries and dead-letters by itself
For large systems

One project, or microservices + Kafka.

Default

One project

One server and one database. Right for shops, booking sites, internal tools and most apps.

  • Up and running in minutes
  • Nothing extra to install
  • Split into services later without rewriting
Optional

Microservices + Kafka

Shop, CRM, accounting and warehouse become separate projects, each with its own server and database, each scaled on its own.

  • Each team ships its own part
  • A slow or broken part never stops the others
  • One event reaches every project that needs it
  • One sign-in across all projects

Choose it when you have several teams, heavy traffic, or parts that must deploy and scale separately. Setup guides for Kafka and multi-service come with the prompts.

Scroll to move the event

How one event travels

01An order is saved, with one outbox row in the same transaction. If the save fails, nothing leaves.
02Within a minute a worker publishes it. Kafka down? The row waits and retries with the same event id.
03Published once on shop.orders · order.paid. The shop never waits for anyone.
04CRM, accounting and warehouse react. Duplicates skipped, failures retried, then dead-lettered.
Keep scrolling
A queue that keeps trying
10 s 1 min 5 min 15 min 1 h DLQ
Built in

What a large system gets, from day one.

Signed calls between projects

Every call carries an HMAC signature that is valid for five minutes and only once. A project accepts calls only from the projects you list, and runs them as the user you choose.

Never done twice

Every change between projects carries an idempotency key. A call or an event that arrives again returns the first result instead of charging, mailing or shipping a second time.

A queue that keeps trying

Calls to other projects leave through the queue and are retried after 10 s, 1 min, 5 min, 15 min and 1 hour. A project that is down for a while misses nothing.

Kafka without the plumbing

Publish with one line of code. Listen by adding a Kafka item with a topic and an event. The Kafka controller routes every message, skips duplicates, retries and dead-letters by itself.

One sign-in for every project

People sign in once on your Auth project and are signed in everywhere, with a normal session on each project. Sign out anywhere and you are signed out everywhere. The mobile app gets short-lived signed tokens.

Built for big tables

Indexes are declared together with the table and created on import. Every prompt forbids full-table scans, N+1 queries and deep paging, and pages that many people read are cached and refresh themselves when their data changes.

Laravel 13 underneath

The engine runs on Laravel 13 and PHP 8.3+, with Redis for cache, sessions and the queue, Supervisor for the workers and one cron line for every scheduled job.

Fast APIs with Octane

Turn on the Octane worker (FrankenPHP) and every /api/view call is answered by an app already loaded in memory. Website, admin and checkout stay on PHP-FPM; one Nginx block turns it off again.

HMAC-SHA256Idempotency-KeyRedis queueKafkaDead-letter topicOAuth2 + PKCERS256 JWTOutboxFULLTEXTKeyset pagingOctane · FrankenPHPSupervisor
Pricing

Pay once. Ship for as long as you want.

From $59, lifetime. Free updates. Unlimited projects on your own server.