DEV Community: Monalisa Das

Event-driven architecture without the Kafka tax — lightweight patterns for small teams

Monalisa Das — Mon, 07 Sep 2026 09:47:45 +0000

Event-driven architecture without the Kafka tax — lightweight patterns for small teams

Most EDA guides assume Kafka, EventBridge, and a platform team to run it. Small teams need the decoupling benefit without the operational weight. Three patterns that get you there with tools you already have.

We had eight engineers. Someone said we should 'add Kafka'. I asked why. The answer was: 'so services can talk to each other without coupling.' I said: 'that is a good goal. Kafka is one way to achieve it. It also needs a cluster, a schema registry, consumer group management, and someone who understands partition rebalancing at 2am.' We did not add Kafka.

What EDA actually is, stripped back

Event-driven architecture is a decoupling technique. Instead of service A calling service B directly, A emits an event -- 'order created', 'payment failed', 'user signed up' -- and B (or C, or D) reacts to it. The publisher does not know or care who is listening. That separation is the value. The message broker is just the delivery mechanism.

Kafka, EventBridge, and RabbitMQ are excellent delivery mechanisms. They are also significant operational commitments. For a team of four to twelve engineers, that commitment often costs more than the problem it solves.

Pattern 1: In-process typed event bus

If your services are modules in a monolith or a modular monorepo, you do not need a network hop to decouple them. An in-process event bus gives you publisher/subscriber separation with zero infrastructure.

stackblitz.com

Live sandbox — scroll up in the terminal to see both patterns run. To experiment: open any file in src/services/, add a new bus.on() listener, save (Ctrl+S), and watch your handler fire without touching any other file. That's the point.

```typescript [TypeScript]
type EventMap = {
'order.created': { orderId: string; customerId: string; total: number }
'order.cancelled': { orderId: string; reason: string }
'payment.failed': { orderId: string; errorCode: string }
}

class EventBus {
// Map of event name to Set of handlers.
// Set (not Array) so unsubscribing is O(1) -- just delete from the Set.
private handlers = new Map void>>()

on(event: K, handler: (payload: EventMap[K]) => void) {
if (!this.handlers.has(event)) this.handlers.set(event, new Set())
this.handlers.get(event)!.add(handler as (payload: unknown) => void)

// Return an unsubscribe function -- call it when the subscriber is torn down.
return () => this.handlers.get(event)?.delete(handler as (payload: unknown) => void)

}

emit(event: K, payload: EventMap[K]) {
this.handlers.get(event)?.forEach(h => h(payload))
}
}

export const bus = new EventBus()

// Publisher -- emits one event and stops thinking about it.
// No idea who is listening or how many listeners there are.
bus.emit('order.created', { orderId: 'ord_123', customerId: 'cus_456', total: 4999 })

// Subscriber -- notification module, registered independently.
// Never imports OrderService. Only knows about the bus and the event type.
bus.on('order.created', ({ orderId, total }) => {
sendConfirmationEmail(orderId, total)
})

// Another subscriber -- analytics module, also independent.
// Added after the fact. Zero changes to the publisher or the other subscriber.
bus.on('order.created', ({ customerId, total }) => {
trackRevenueEvent(customerId, total)
})






```csharp [C# / .NET 8]
// C# / .NET 8 -- same pattern, different syntax.
// C# has built-in events and delegates. I could have used those.
// But this shows the pattern clearly -- it's an idea, not a language feature.

public sealed class EventBus
{
    // Dictionary maps event name to list of handlers.
    // Same structure as the TypeScript Map -- just C# syntax.
    private readonly Dictionary<string, List<Action<object>>> _handlers = new();

    public Action Subscribe<TPayload>(string eventName, Action<TPayload> handler)
    {
        if (!_handlers.ContainsKey(eventName))
            _handlers[eventName] = new List<Action<object>>();

        // Wrap the typed handler so the dictionary can store it generically.
        Action<object> wrapped = payload => handler((TPayload)payload);
        _handlers[eventName].Add(wrapped);

        // Return an unsubscribe action -- same as the TypeScript version.
        return () => _handlers[eventName].Remove(wrapped);
    }

    public void Publish<TPayload>(string eventName, TPayload payload)
    {
        if (!_handlers.TryGetValue(eventName, out var handlers)) return;
        foreach (var h in handlers) h(payload!);
    }
}

// Records are perfect for event types -- immutable value objects.
// An event that already happened should not be mutable.
public record OrderCreated(string OrderId, string CustomerId, decimal Total);
public record PaymentFailed(string OrderId, string ErrorCode);

// Usage
var bus = new EventBus();

// Publisher -- knows nothing about who is listening
bus.Publish("order.created", new OrderCreated("ord_123", "cus_456", 49.99m));

// Subscribers -- registered independently, no cross-imports
bus.Subscribe<OrderCreated>("order.created", e => SendConfirmationEmail(e.OrderId, e.Total));
bus.Subscribe<OrderCreated>("order.created", e => TrackRevenueEvent(e.CustomerId, e.Total));

The EventMap type makes this refactor-safe -- TypeScript will error if a publisher emits the wrong shape or a subscriber reads a field that does not exist. The return value of on is an unsubscribe function, so there are no memory leaks in short-lived contexts.

The limitation: events do not survive a process restart, and they do not cross service boundaries. That is fine for most intra-module communication. When you need durability or cross-service delivery, reach for the next pattern.

Pattern 2: Postgres as an event store (the outbox pattern)

You already have a database. Use it. An append-only events table is a durable event log that costs you nothing new to operate.

-- One migration. No new infrastructure.
CREATE TABLE events (
  id          BIGSERIAL PRIMARY KEY,
  type        TEXT        NOT NULL,
  payload     JSONB       NOT NULL,
  occurred_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  processed   BOOLEAN     NOT NULL DEFAULT false
);
CREATE INDEX ON events (processed, occurred_at) WHERE NOT processed;

The outbox pattern: write the event in the same database transaction as your domain change. This guarantees the event is emitted if and only if the domain change commits -- no dual-write inconsistency.

```typescript [TypeScript]
// Publisher: domain change + event in one transaction.
// If the transaction rolls back, the event never exists.
// That is the guarantee the outbox pattern gives you.
async function createOrder(db: Pool, order: NewOrder): Promise {
await db.transaction(async (trx) => {
await trx.query(
'INSERT INTO orders (id, customer_id, total) VALUES ($1, $2, $3)',
[order.id, order.customerId, order.total]
)
await trx.query(
'INSERT INTO events (type, payload) VALUES ($1, $2)',
['order.created', JSON.stringify({ orderId: order.id, total: order.total })]
)
})
}

// Consumer: poll for unprocessed events on a schedule (cron or setInterval).
// FOR UPDATE SKIP LOCKED lets you run multiple consumers safely --
// locked rows are skipped, so two workers never process the same event.
async function processEvents(db: Pool): Promise {
const { rows } = await db.query(SELECT id, type, payload FROM events WHERE NOT processed ORDER BY occurred_at LIMIT 20 FOR UPDATE SKIP LOCKED)

for (const event of rows) {
await handleEvent(event.type, event.payload)
await db.query('UPDATE events SET processed = true WHERE id = $1', [event.id])
}
}






```csharp [C# / .NET 8]
// C# / .NET 8 -- using Npgsql + Dapper.
// Same SQL, same guarantees. The pattern does not change between languages.

async Task CreateOrder(NpgsqlConnection conn, Order order)
{
    using var trx = await conn.BeginTransactionAsync();

    // Domain write and event write in the same transaction.
    await conn.ExecuteAsync(
        "INSERT INTO orders (id, customer_id, total) VALUES (@Id, @CustomerId, @Total)",
        order, transaction: trx);

    await conn.ExecuteAsync(
        "INSERT INTO events (type, payload) VALUES (@Type, @Payload::jsonb)",
        new {
            Type    = "order.created",
            Payload = JsonSerializer.Serialize(new { order.Id, order.Total })
        },
        transaction: trx);

    await trx.CommitAsync();
    // CommitAsync throws on failure -- the event never exists if the order did not save.
}

// Consumer -- FOR UPDATE SKIP LOCKED is the same SQL in every language
async Task ProcessEvents(NpgsqlConnection conn)
{
    var events = await conn.QueryAsync<StoredEvent>(@"
        SELECT id, type, payload
        FROM   events
        WHERE  NOT processed
        ORDER  BY occurred_at
        LIMIT  20
        FOR UPDATE SKIP LOCKED");

    foreach (var ev in events)
    {
        await HandleEvent(ev.Type, ev.Payload);
        await conn.ExecuteAsync(
            "UPDATE events SET processed = true WHERE id = @Id",
            new { ev.Id });
    }
}

FOR UPDATE SKIP LOCKED is the key. It lets multiple consumer processes poll the same table without stepping on each other -- locked rows are skipped rather than blocking. You get basic fan-out and parallelism with a single SQL clause.

Pattern 3: Combine them

In practice I use both. The in-process bus handles immediate, same-process reactions -- send a notification, update an in-memory cache. The Postgres event table handles durability and cross-service work. The domain service writes to the DB events table; a separate consumer process polls it and emits on the in-process bus for local handlers to pick up.

The two patterns layer cleanly: persistence at the boundary, speed in the core. You add a message broker later if and when throughput demands it -- and by then, your event contracts are already defined and tested.

When you actually need Kafka

Three signals: your event table is being polled so frequently that it is a meaningful fraction of your database load; you need guaranteed ordering across partitions that a single Postgres table cannot provide; or you have genuinely independent services deployed across teams who need a shared contract enforced by a schema registry. Those are real problems. They are also problems most teams do not have until well past the point where they can afford to solve them properly.

Start with the patterns that match your current scale. Migrate to a broker when the polling table actually hurts -- not when someone reads a blog post about Kafka. You will know when. Your database will tell you.

React 19 useActionState — from useState chaos to server-action clarity

Monalisa Das — Mon, 07 Sep 2026 09:43:31 +0000

Every form I've built in React has the same boilerplate: loading state, error state, success message — three useStates for one button click. React 19's useActionState replaces all of it.

Every form I've built in React has the same boilerplate. Loading state. Error state. Maybe a success message. Three useStates for one button click.

const [loading, setLoading] = useState(false)
const [error, setError] = useState<string | null>(null)
const [success, setSuccess] = useState(false)

async function handleSubmit(e: React.FormEvent) {
  e.preventDefault()
  setLoading(true)
  setError(null)
  try {
    await submitContactForm(formData)
    setSuccess(true)
  } catch (err) {
    setError(err instanceof Error ? err.message : 'Something went wrong')
  } finally {
    setLoading(false)
  }
}

I wrote this pattern in my first React project. I've written it a hundred times since. It's not wrong — it just shouldn't exist.

React 19 ships useActionState

One hook. Replaces all three.

import { useActionState } from 'react'

type State = { success: boolean; error: string | null }

async function submitAction(prevState: State, formData: FormData): Promise<State> {
  try {
    await submitContactForm(formData)
    return { success: true, error: null }
  } catch (err) {
    return { success: false, error: err instanceof Error ? err.message : 'Failed' }
  }
}

function ContactForm() {
  const [state, action, isPending] = useActionState(submitAction, {
    success: false,
    error: null,
  })

  return (
    <form action={action}>
      <input name="email" type="email" required />
      <button type="submit" disabled={isPending}>
        {isPending ? 'Sending…' : 'Send'}
      </button>
      {state.error && <p className="error">{state.error}</p>}
      {state.success && <p className="success">Sent!</p>}
    </form>
  )
}

No onSubmit. No e.preventDefault(). The action prop on the form handles it. isPending replaces the loading state. The returned state object replaces error and success. React manages the pending flag automatically — you just read it.

The hook signature

const [state, action, isPending] = useActionState(
  actionFn,      // async (prevState, formData) => newState
  initialState,  // what state is before the first submit
  permalink?     // optional URL for progressive enhancement
)

The action function always receives prevState as its first argument, then formData. It returns whatever becomes the new state — any shape you define. That state persists across renders and re-submits.

With server actions (Next.js 14+)

This is where it gets genuinely useful. The action can live on the server. No API route. No fetch. No JSON.stringify.

// app/actions.ts
'use server'

type State = { success: boolean; error: string | null }

export async function submitContactForm(
  prevState: State,
  formData: FormData
): Promise<State> {
  const email = formData.get('email') as string
  if (!email) return { success: false, error: 'Email is required' }

  await db.contacts.insert({ email, createdAt: new Date() })
  return { success: true, error: null }
}

// app/contact/page.tsx
'use client'
import { useActionState } from 'react'
import { submitContactForm } from '../actions'

export function ContactForm() {
  const [state, action, isPending] = useActionState(submitContactForm, {
    success: false,
    error: null,
  })

  return (
    <form action={action}>
      <input name="email" type="email" required />
      <button type="submit" disabled={isPending}>
        {isPending ? 'Sending…' : 'Send'}
      </button>
      {state.error && <p className="error">{state.error}</p>}
      {state.success && <p>Done. I'll be in touch.</p>}
    </form>
  )
}

The server action crosses the boundary automatically. The client component doesn't know or care that the function runs on the server. The form works even with JavaScript disabled — the browser just submits it the old-fashioned way.

Two things I got wrong the first time

First: I kept passing the action to onSubmit instead of the form's action prop. The hook doesn't intercept events — it works with the native form submission. Pass it to action, not onSubmit.

Second: the action function signature is (prevState, formData), in that order. I kept writing async function submit(formData: FormData) and then wondering why formData looked wrong. prevState is always first, even if you ignore it.

Worth switching for?

stackblitz.com

Run the state machine demo — see how useActionState manages isPending and prevState without React

If you're managing form loading and error state manually — yes, immediately. Zero bundle cost, it's built into React 19. The refactor is maybe 15 minutes per form. You end up with less code, fewer useState calls, and cleaner components. If you're on Next.js and not yet using server actions, that's the bigger unlock — but useActionState works fine with regular async functions too. Start there.

You're shipping on a dead toolchain. The CRA Vite escape guide for the weekend.

Monalisa Das — Sun, 06 Sep 2026 19:01:51 +0000

You're shipping on a dead toolchain. The CRA → Vite escape guide for this weekend.

CRA (Create React App) is officially deprecated and teams stuck on it are searching for a fast, low-risk path to Vite. Here's the complete migration in order — env vars, config, SVGs, aliases, and the four gotchas nobody warns you about.

I migrated three CRA projects to Vite last month. The first one took a Saturday afternoon. The second took two hours. The third took forty minutes. The pattern is the same every time — a handful of specific changes in a specific order, and then it's done. This post is that order.

CRA was officially deprecated in March 2023. The React team removed it from the docs in 2024. In 2026, if you're still running react-scripts, you're running unpatched webpack under a dead project. Every npm audit is a reminder. React 19's install warnings make it worse. The exit is less work than it looks.

Why Vite is the right replacement

Vite's dev server doesn't bundle. It serves native ESM and lets the browser resolve imports. Cold start goes from 15–30 seconds on a large CRA project to under a second. HMR updates in milliseconds instead of seconds. Production builds use esbuild (fast) + Rollup (correct tree-shaking). The ecosystem matches: every React framework — Remix, Next, TanStack Start — either uses Vite or is compatible with it.

Step 1 — Install Vite and the React plugin

# Install Vite and the React plugin
npm install --save-dev vite @vitejs/plugin-react

Step 2 — Create vite.config.ts

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import svgr from 'vite-plugin-svgr'  // only if you import SVGs as components
import path from 'path'

export default defineConfig({
  plugins: [
    react(),
    svgr(),  // remove if you have no SVG component imports
  ],
  resolve: {
    alias: {
      // mirrors tsconfig "paths" — both must stay in sync
      '@': path.resolve(__dirname, './src'),
    },
  },
})

If you don't use SVG imports as React components, skip vite-plugin-svgr entirely. If you don't use @/ absolute imports, skip the resolve.alias block. Start minimal and add only what breaks.

Step 3 — Move index.html to the project root

CRA owns public/index.html and injects scripts automatically. Vite doesn't — you own the file and you wire it up yourself. Move it from public/ to the project root, then add one line at the bottom of :

<!-- index.html at project root, not public/ -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>My App</title>
  </head>
  <body>
    <div id="root"></div>
    <!-- This line is new — Vite needs it to find your entry point -->
    <script type="module" src="/src/main.tsx"></script>
  </body>
</html>

Also remove every %PUBLIC_URL% reference. CRA replaced that at build time; Vite does not. Replace with / or a relative path — Vite serves from the project root by default.

Step 4 — Update package.json scripts

{
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "preview": "vite preview"
  }
}

Note the separate tsc in the build script. CRA ran type-checking silently in the background and never blocked the build. Vite doesn't type-check — esbuild strips types, it doesn't verify them. Running tsc first means a type error actually fails the build. This is the correct behaviour.

Step 5 — Rename env variables

This is the most tedious step but it's mechanical. CRA uses REACT_APP_ as the required prefix. Vite uses VITE_. Every variable in every .env file needs renaming, and every usage in source needs updating.

# Find every env var reference in source
grep -r "REACT_APP_" src/
grep -r "process.env" src/

// Before — CRA
const apiUrl = process.env.REACT_APP_API_URL

// After — Vite
const apiUrl = import.meta.env.VITE_API_URL

// Vite also gives you these for free, no prefix needed:
// import.meta.env.MODE   → 'development' | 'production'
// import.meta.env.DEV    → true in dev
// import.meta.env.PROD   → true in production

Step 6 — Update tsconfig.json

{
  "compilerOptions": {
    "target": "ES2020",
    "useDefineForClassFields": true,
    "module": "ESNext",
    "moduleResolution": "bundler",
    "types": ["vite/client"],
    "paths": { "@/*": ["./src/*"] },
    "baseUrl": ".",
    "strict": true,
    "jsx": "react-jsx"
  }
}

The critical changes: module from commonjs to ESNext, moduleResolution to bundler (new in TS 5, matches how Vite resolves), and types: ["vite/client"] which gives you proper types for import.meta.env. Without that last one, TypeScript will complain about import.meta.

The four gotchas that will bite you

require() calls in your source files. Vite outputs native ESM — require() doesn't exist. Search for it globally and replace with import statements. If you genuinely need require for a Node interop case, use createRequire from 'module'.
process.env references you missed. import.meta.env only exposes VITE_* variables. Anything else — process.env.NODE_ENV, process.env.npm_package_version — is undefined at runtime. Run grep -r "process.env" src/ after your initial pass and fix every remaining hit.
SVG component imports. CRA's webpack config handled import { ReactComponent as Logo } from './logo.svg' via a built-in loader. Vite doesn't. Install vite-plugin-svgr and change the import to import Logo from './logo.svg?react'. The query string ?react is Vite's way of routing the import through the SVGR transform.
Jest tests. Vite is not a Jest runner. If you're using react-scripts test, your test setup is CRA's Jest config. Don't fix this on the same day as the migration — get the app running first. Then either switch to Vitest (same config file as Vite, near-identical API) or keep Jest by installing babel-jest and a Babel config.

Verify the migration

# These three commands should all succeed cleanly
npm run dev       # → app opens at localhost:5173, HMR works
npm run build     # → dist/ produced with no type errors
npm run preview   # → serves built dist/ locally at localhost:4173

If npm run dev opens your app and hot reload works, and npm run build produces a dist/ folder without errors — you're done. The migration is complete. The three commands above are your acceptance criteria.

Step 7 — Remove react-scripts

Once npm run build succeeds with no errors, react-scripts has done its job. Remove it:

npm uninstall react-scripts

What I want you to notice

The migration is not one big refactor. It's six small, independent changes that each target one CRA assumption. You can do them in order and test after each step. The sandbox below walks through every change in code — run it before you start so you have a reference for what maps where.

stackblitz.com

CRA → Vite Migration Map — interactive reference

CRA served its purpose for years. It lowered the barrier to starting a React project when the tooling landscape was genuinely confusing. That era is over — Vite is faster, smaller, and the default for everything new. The migration is a Saturday morning. Do it before it becomes someone else's emergency.