DEV Community: Monalisa Das

Whether agentic AI failures in production are a model-capability problem or an architecture problem

Monalisa Das — Wed, 23 Sep 2026 15:00:00 +0000

Agentic AI failures aren't a model problem.

They're an architecture problem — and most teams only figure this out after they've already upgraded the model twice.

The debugging loop I've seen: flaky agent → swap in a bigger model → still flaky → add more context window → still flaky → eventually realize there's no retry logic, no verification gate between steps, no state that can recover mid-task.

A model call is non-deterministic. You wouldn't call an external API without error handling and retries. But "call the LLM and trust the output" is exactly what most agent pipelines do in production.

The fix isn't a smarter model. It's designing at the orchestration layer — retry budgets per step, verification gates that catch bad output before it propagates, HITL checkpoints for decisions you can't undo.

"Agents are unreliable" is the symptom. Missing scaffolding is the diagnosis.

Is your agent pipeline designed to tolerate a 30% failure rate on any given step — or are you counting on the model to never fail?

https://www.trantorinc.com/blog/ai-agent-failure-modes-what-goes-wrong-design-resilience

TypeScript Type System Tricks That Changed How I Code

Monalisa Das — Tue, 22 Sep 2026 14:30:00 +0000

Once you understand TypeScript's type system as a programming language in its own right, everything changes. Here are the patterns that made me a better TypeScript developer.

Most TypeScript developers use maybe 20% of the type system. They annotate functions, use interfaces, maybe throw in a generic here and there. But TypeScript's type system is genuinely Turing-complete — you can do computation at the type level. Here's what that unlocks.

Template Literal Types

Template literal types let you construct new string types by combining existing ones. This is incredibly useful for building type-safe event systems, CSS-in-JS APIs, and routing.

type EventName = 'click' | 'focus' | 'blur'
// Capitalize is a built-in TypeScript utility -- turns 'click' into 'Click'
type Handler = `on${Capitalize<EventName>}` // 'onClick' | 'onFocus' | 'onBlur'

// Here's why this matters: the compiler knows every valid prop name
// You can't pass 'onDoubleclick' -- it won't compile
type Side = 'top' | 'right' | 'bottom' | 'left'
type Spacing = `margin-${Side}` | `padding-${Side}`
// 'margin-top' | 'margin-right' | ... | 'padding-left'
// All 8 strings, derived from 2 unions -- no manual list

Discriminated Unions with Exhaustive Checks

The most underused TypeScript pattern. Model your state as a discriminated union and let the compiler tell you when you've forgotten a case.

// Every possible state is explicit -- no boolean flags that combine illegally
type AsyncState<T> =
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; data: T }   // data only exists in success
  | { status: 'error'; error: Error } // error only exists in error

// assertNever: if TypeScript lets you reach this line, you missed a case
// It's a compile-time guarantee, not a runtime one
function assertNever(x: never): never {
  throw new Error('Unexpected value: ' + x)
}

function render<T>(state: AsyncState<T>) {
  switch (state.status) {
    case 'idle':    return <Idle />
    case 'loading': return <Spinner />
    case 'success': return <Data value={state.data} /> // state.data is T here, not T | undefined
    case 'error':   return <ErrorView error={state.error} />
    default:        return assertNever(state) // Remove a case above -- this line turns red
  }
}

Infer in Conditional Types

The infer keyword lets you extract parts of a type within a conditional. This powers utilities like ReturnType, Awaited, and Parameters — and you can build your own.

// 'infer R' means: if T matches Promise<something>, capture that something as R
type Awaited<T> = T extends Promise<infer R> ? R : T

// Same idea -- capture the element type out of an array
type ElementOf<T> = T extends Array<infer E> ? E : never

// Capture just the first argument, ignore the rest
type FirstArg<F> = F extends (first: infer A, ...rest: any[]) => any ? A : never

type A = FirstArg<(name: string, age: number) => void> // string
// These aren't magic -- the compiler checks the shape,
// and infer gives you a name to use on the right-hand side

stackblitz.com

Run the demos yourself — template literals, discriminated unions, and infer all in one TypeScript file

These three patterns cover 80% of what 'advanced TypeScript' actually means in practice. Template literals for string type composition. Discriminated unions for modelling state correctly. Infer for writing your own type utilities. Once you're comfortable with them, you stop fighting the type system and start using it as a design tool.

Always reach for the asymptotically-optimal data structure — challenged

Monalisa Das — Mon, 21 Sep 2026 15:30:00 +0000

Everyone reaches for the hash map. O(1) lookup — can't beat that, right? Wrong.

For most production lookups, a flat array with a linear scan is faster. I've seen this matter in real systems. Not because Big-O is a lie. Because Big-O describes the shape of the curve, not the constant factor. A hash map pays a hashing cost on every call. Its bucket array scatters across memory — cache miss after cache miss. A small flat array fits in one or two cache lines. The CPU prefetches it for you. Chandler Carruth demonstrated this concretely at CppCon 2014 — linear search beating hash-map lookup for small but realistic N. Not in theory. In measured wall-clock time.

Think about what most production lookups actually touch: a short config list, a few dozen enum values, an in-memory cache with 20 entries. That's not large N. That's small N, every time. Big-O tells you what happens as N grows unbounded. Most of your data will never get there. Profile before you optimize for an asymptote your code will never reach.

https://www.youtube.com/watch?v=fHNmRkzxHWs

React Performance Patterns I Use Every Day

Monalisa Das — Thu, 17 Sep 2026 14:30:00 +0000

After profiling dozens of React apps, the same culprits appear again and again. Here are the patterns I reach for first — and the ones that look smart but actually hurt.

Performance optimization in React is one of those areas where intuition frequently leads you astray. Developers reach for useMemo everywhere, wrap every function in useCallback, and then wonder why their app is slower. Let me share what actually moves the needle.

1. Colocate State as Low as Possible

The single biggest source of unnecessary re-renders is state that lives too high in the tree. If only one child needs a piece of state, keep it in that child. Every time that state updates, only that subtree re-renders.

// Bad: hover state lives at App level -- every hover event re-renders the entire tree
function App() {
  const [hovered, setHovered] = useState(false)
  return <HugeTree><Button onHover={setHovered} /></HugeTree>
}

// Good: hover state is local to Button -- only Button re-renders on hover
// HugeTree is completely unaffected. This is the fix that costs zero effort
function Button() {
  const [hovered, setHovered] = useState(false)
  return <button onMouseEnter={() => setHovered(true)} />
}

2. Use Refs for Values That Don't Drive UI

Not all values need to be state. If a value changes frequently but doesn't need to trigger a re-render, use a ref. The classic example is storing the previous value of a prop, or tracking animation frame IDs.

// Canvas animation: mouse position changes 60 times/second
// If this were useState, React would try to re-render 60 times/second
function Canvas() {
  const mousePos = useRef({ x: 0, y: 0 }) // Ref: mutation doesn't schedule a render
  const canvasRef = useRef<HTMLCanvasElement>(null)

  useEffect(() => {
    const onMove = (e: MouseEvent) => {
      mousePos.current = { x: e.clientX, y: e.clientY }
      // Draw directly to canvas -- zero React involvement, zero re-renders
      draw(canvasRef.current!, mousePos.current)
    }
    window.addEventListener('mousemove', onMove)
    return () => window.removeEventListener('mousemove', onMove)
  }, []) // Empty deps: we read mousePos.current at event time, not render time
}

3. Memo Boundaries, Not Individual Values

Instead of sprinkling useMemo everywhere, identify the expensive component subtrees and wrap them with React.memo. Then ensure their props are stable — that's where useMemo and useCallback actually pay off.

4. Virtualize Long Lists

If you're rendering more than ~100 rows, virtualize. @tanstack/virtual is my go-to — it's framework-agnostic, tiny, and handles variable-height rows elegantly. The DOM node count drops from thousands to ~20 regardless of list length.

stackblitz.com

Run the demos — see colocated state and refs eliminate re-renders without useMemo everywhere

The order matters: colocate state first, it's free and usually fixes 80% of the problem. Only then measure — React DevTools Profiler will tell you exactly which components re-render on each update. Don't reach for useMemo until you've measured where time is actually going.

Stop manually memoizing every callback — the React Compiler already does it better than you can.

Monalisa Das — Thu, 17 Sep 2026 14:30:00 +0000

The React Compiler does your memoization better than you do. Stop wrapping every callback in useCallback "just in case."

React 19's compiler statically analyzes your component tree at build time and inserts exactly the right memoization - no dependency arrays to maintain, no closures retained longer than necessary, no guesswork. Hand-rolling it adds three things: cognitive load for the next person reading the code, a dependency array that will silently go stale, and closure memory pressure from retaining an entire scope you didn't mean to.

Most re-renders are cheap. The comparisons useMemo and useCallback add to "prevent" them have their own cost - one you haven't measured against the render you're trying to avoid.

"Wrap it just in case" was a reasonable heuristic in 2018. In 2025 with React 19 in production, it's solving a solved problem while leaving a dependency array for the next reviewer to audit and get wrong.

Profile first. Memoize second. Let the compiler handle the rest.

React Compiler — automatic memoization, reached 1.0 stable Oct 2025, now default in Next.js 16 / Vite / Expo templates:
react.dev/learn/react-compiler

Code review wasn't designed for this volume

Monalisa Das — Wed, 16 Sep 2026 14:30:00 +0000

GitHub says 1-in-5 PRs now involve an agent. LinearB found agentic PRs take 5.3x longer to even get picked up. We tripled throughput without redesigning the process - then blamed the AI when 81% of orgs reported more production incidents (CloudBees, 2024).

Dev trust in AI code dropped from 40% to 29% in a year (Stack Overflow). That's not a quality gap. It's a "reviewing the wrong artifact" problem.

The shift I've seen work: less investment in line-by-line diff review, more in contracts that make bad agent output fail loudly before anyone reads it - strong types, property tests, invariant assertions that say "a correct implementation here cannot return null" and catch it in CI, not a PR comment at 4pm.

"Verify, don't review" isn't a shortcut. It's the only model that scales when PR count triples and reviewer time doesn't.

Where's your team's bet - better prompts and more reviewers, or tighter contracts?

Sources for the data in this post:

📊 LinearB 2026 Engineering Benchmarks — agentic PRs wait 5.3x longer for reviewer pickup (1,055 min vs 201 min), analyzed across 8.1M PRs:
linearb.io/dev-interrupted/podcast/linearb-2026-benchmarks-ai-pr-merge-rate

📊 CloudBees "State of Code Abundance 2026" — 81% of enterprise tech leaders report production failures from AI-generated code (functional errors, security vulnerabilities, performance issues):
cloudbees.com/newsroom/enterprise-technology-leaders-report-production-failures-from-ai-generated-code

📊 Stack Overflow Developer Survey 2025 — trust in AI output accuracy dropped from 40% (2024) to 29% (2025):
survey.stackoverflow.co/2025

Container Queries Are Here and They're a Game Changer

Monalisa Das — Tue, 15 Sep 2026 14:30:00 +0000

Media queries have always felt wrong — why does a sidebar card care about the browser window width? Container queries solve this elegantly and they're now supported everywhere.

For years, we hacked around a fundamental limitation: media queries respond to the viewport, not the container an element lives in. A card component inside a narrow sidebar behaved identically to the same card in a full-width grid, even though the available space was completely different.

The Problem with Media Queries

Imagine a <BlogCard> component. In a sidebar it gets 280px. In a grid it gets 400px. In a hero it gets 800px. With media queries, you'd need to know the context of each usage and write specific overrides. With container queries, the card simply responds to how much space it actually has.

/* Step 1: declare which element is the container */
/* inline-size: responds to width only (most common) */
.card-wrapper {
  container-type: inline-size;
  container-name: card; /* name it so nested @container can target it */
}

.card {
  display: flex;
  flex-direction: column; /* default: stacked layout for narrow containers */
  gap: 1rem;
}

/* Step 2: query the container's size, not the viewport */
/* This fires when .card-wrapper is >= 400px, regardless of screen width */
@container card (min-width: 400px) {
  .card {
    flex-direction: row; /* side-by-side when there's room */
    align-items: center;
  }

  .card-image {
    width: 160px;
    flex-shrink: 0; /* image stays 160px even in flex layout */
  }
}

Container Query Units

Container queries also introduced new length units: cqw (1% of container width), cqh, cqi (inline), cqb (block), cqmin, and cqmax. These let you size elements relative to their container rather than the viewport — a typography dream.

.card-title {
  /* Font scales with the card width, not the screen */
  /* clamp: min 1rem, scales at 4% of container width, caps at 2rem */
  /* In a narrow container: stays at 1rem. Wide container: grows proportionally */
  font-size: clamp(1rem, 4cqw, 2rem);
}

Browser Support

As of early 2024, container queries have 92%+ global browser support (Chrome 105+, Firefox 110+, Safari 16+). There's no longer any reason to avoid them in production. The polyfill is also solid for the remaining edge cases.

stackblitz.com

See container queries in action — resize the container and watch the card layout respond

Start by finding one component in your codebase that has different layouts depending on where it's placed — a card, a header, a media block. Add container-type: inline-size to its wrapper and replace the media query overrides with @container rules. Once you see how much simpler the component becomes, you won't go back.

More agents = more intelligence?

Monalisa Das — Thu, 10 Sep 2026 14:30:00 +0000

Multi-agent orchestration isn't "more powerful." It's usually a more expensive way to get worse reasoning.

Every agent-to-agent handoff is a lossy compression step. The receiving agent never sees the nuance the previous one worked through — only its sanitised summary. Google's own research found multi-agent coordination dropped sequential reasoning performance by 39–70%. A Sber whitepaper clocked ~15x the token usage versus single-agent chat.

Multi-agent earns its overhead in exactly one scenario: the work is genuinely parallel, or too large for a single context window. Everything else? A single agent with good tools and enough context will out-reason your swarm — at a fraction of the cost.

The "more agents = more intelligence" playbook is hype math, not engineering math. What do you think? 👇

Towards a science of scaling agent systems: When and why agent systems work

research.google

AI #AgenticAI #LLM #SoftwareArchitecture #AIEngineering

Building reliable agentic pipelines — retries, fallbacks, and observability

Monalisa Das — Thu, 10 Sep 2026 14:30:00 +0000

Agent demos work. Production agents break — tool failures, context overflow, silent loops, hallucinated JSON. Four patterns that close the gap: retry, fallback, loop detection, and structured observability.

The demo worked. Flawlessly. The agent found the customer record, pulled the transaction history, summarized it, and drafted the response in under four seconds. We showed it to the team on a Friday. Monday morning, in a production load test, it hung. For eleven minutes. Then crashed.

The gap nobody talks about

Agent demos work because they run on clean inputs, stable APIs, and a single user. Production means flaky third-party tool endpoints, context windows that overflow mid-conversation, loops that spin silently because no exit condition matched, and hallucinations that look like valid JSON until you try to reserialize them.

I ran into all four building the AI chatbot for my company product, Weeve. Here is what I added to close the gap.

Pattern 1: Retry with exponential backoff

Tool call failures are the most common production failure mode. An external API returns a 503. A database query times out under load. The agent's default behaviour: propagate the error and crash the run.

// Generic retry wrapper -- works around any async function, not just agent tool calls
async function withRetry<T>(
  fn: () => Promise<T>,
  { maxAttempts = 3, baseDelayMs = 500 }: { maxAttempts?: number; baseDelayMs?: number } = {}
): Promise<T> {
  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    try {
      return await fn()
    } catch (err) {
      if (attempt === maxAttempts) throw err // Last attempt -- let it propagate
      // Math.pow(2, attempt - 1): 1x, 2x, 4x -- backs off exponentially
      const delay = baseDelayMs * Math.pow(2, attempt - 1)
      await new Promise(res => setTimeout(res, delay))
    }
  }
  throw new Error('unreachable') // TypeScript needs this -- the loop always returns or throws
}

// Wrap any tool call -- the agent code stays unchanged
const result = await withRetry(
  () => externalCrmApi.getCustomer(customerId),
  { maxAttempts: 3, baseDelayMs: 300 }
)

Double the delay on each retry (exponential backoff) to avoid hammering an already-struggling API. For non-idempotent operations — writes, payments — don't retry automatically. Flag them for human review instead.

Pattern 2: Fallback when retries exhaust

Retries handle transient failures. Persistent failures need a fallback path — something the agent can do when the primary tool is unavailable, rather than returning nothing.

async function withFallback<T>(
  primary: () => Promise<T>,
  fallback: () => Promise<T>
): Promise<T> {
  try {
    // Try primary with a quick retry budget -- don't wait too long before giving up
    return await withRetry(primary, { maxAttempts: 2, baseDelayMs: 200 })
  } catch {
    // Primary exhausted its retries -- fall back instead of propagating the error
    return await fallback()
  }
}

// Real usage: live data -> cached snapshot when live is unavailable
const customerData = await withFallback(
  () => liveApi.getCustomer(customerId),
  () => cache.getLastKnownCustomer(customerId) // Stale but useful
)

Fallbacks keep the agent useful under degraded conditions. A cached snapshot is worse than live data — but it is infinitely better than a crashed run and a blank response.

Pattern 3: Loop detection

Infinite loops are silent in agentic systems. The agent calls a tool, gets an ambiguous result, decides it needs more information, calls the same tool again. No exception is raised. The loop spins until the context window overflows or the timeout kills it.

interface AgentStep {
  toolName: string
  input: string
}

// windowSize: only check the last N steps -- agents can revisit tools legitimately over a long run
function detectLoop(steps: AgentStep[], windowSize = 6): boolean {
  if (steps.length < windowSize) return false
  const recent = steps.slice(-windowSize)
  const seen = new Set<string>()
  for (const step of recent) {
    // Fingerprint = tool name + serialised input -- catches exact repeats
    const key = `${step.toolName}:${step.input}`
    if (seen.has(key)) return true // Same call twice in the window = loop
    seen.add(key)
  }
  return false
}

// Check after every step in the agent run loop
if (detectLoop(executedSteps)) {
  throw new Error(
    `Agent loop detected after ${executedSteps.length} steps -- breaking run`
  )
}

Fingerprint each step as tool name + serialised input. If you see the same fingerprint twice in a short window, you have a loop. Break it loudly — an error you can catch and log is better than a silent timeout.

Pattern 4: Structured observability

Logging 'agent failed' is not observability. Observability for an agent run means knowing: which tool was called, with what arguments, how long it took, what it returned, and what the agent decided to do next.

interface AgentSpan {
  runId: string     // Ties all spans for one agent run together
  step: number      // Execution order within the run
  toolName: string
  inputSummary: string
  durationMs: number
  success: boolean
  errorMessage?: string
  outputSummary?: string
}

// Wrap every tool call with this -- don't call tools directly
async function tracedToolCall(
  runId: string,
  step: number,
  toolName: string,
  args: unknown,
  fn: () => Promise<unknown>
): Promise<unknown> {
  const start = Date.now()
  const inputSummary = JSON.stringify(args).slice(0, 200) // Truncate large inputs
  try {
    const result = await fn()
    await observabilityStore.write({
      runId, step, toolName, inputSummary,
      durationMs: Date.now() - start,
      success: true,
      outputSummary: JSON.stringify(result).slice(0, 200),
    } satisfies AgentSpan) // satisfies: compiler checks shape without widening the type
    return result
  } catch (err) {
    await observabilityStore.write({
      runId, step, toolName, inputSummary,
      durationMs: Date.now() - start,
      success: false,
      errorMessage: err instanceof Error ? err.message : String(err),
    } satisfies AgentSpan)
    throw err // Re-throw so the agent run still sees the failure
  }
}

Every tool call is a span. The runId ties all spans for a single agent run together — so when something fails, you can reconstruct exactly what happened, in order. This is the difference between debugging production and guessing about it.

How they work together

In production, these four patterns compose. The agent run starts with a runId. Every tool call goes through tracedToolCall, which wraps retry and fallback internally, logs each attempt as a span, and records failures without crashing the run. After each step, the loop detector scans the last six steps. If a loop is found, it throws — which gets caught, logged as a terminal span, and returned to the caller as a structured error rather than a silent hang.

The result: agent runs that degrade gracefully, fail loudly, and leave a breadcrumb trail you can actually follow. Not the demo. The thing that runs on Monday morning.

stackblitz.com

Run all four patterns yourself — retry, fallback, loop detection, and observability wired together

"One of the dumbest things" ?

Monalisa Das — Wed, 09 Sep 2026 03:15:00 +0000

An AWS CEO said companies cutting junior engineers because of AI is "short-sighted thinking dressed up as efficiency" he's heard. I agree. But not for the reason most people are arguing.

The productivity gap is real — seniors are reportedly getting far more out of AI tools than juniors. Companies are reading that as "juniors are obsolete." They're reading it wrong.

Pairing and code review never just transferred code. They transferred judgment. That transfer happened because people needed each other — senior needs their task done, junior needs to learn, the code review loop is where both things happen simultaneously. AI quietly removes that dependency. Firms cutting junior hiring now aren't just saving headcount. They're deleting their own senior pipeline for 2030.

I've mentored juniors through code review for years. The gap between a junior who's been paired with a senior and one who hasn't, isn't a skills gap — it's a judgment gap. AI can close the first one. Nobody's built the thing that closes the second.

We always said the industry has a pipeline problem. Aren't we about to make it structurally worse and call it efficiency?

So, are you seeing junior hiring freeze at your company — and if so, what's the plan for where the next batch of seniors comes from? 💭 Tell me your thoughts! 👇

SoftwareEngineering #AI #EngineeringCulture #TechHiring #CareerDevelopment

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

Monalisa Das — Mon, 07 Sep 2026 18:55:39 +0000

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.

// EventMap is the contract. Every event name and its payload shape, in one place.
// If you emit the wrong data, TypeScript tells you before it ships.
type EventMap = {
  'order.created':   { orderId: string; customerId: string; total: number }
  'order.cancelled': { orderId: string; reason: string }
  'payment.failed':  { orderId: string; errorCode: string }
  'payment.ok':      { orderId: string }
}

class EventBus {
  // Map of event name → Set of handlers.
  // Set (not Array) so the same handler can't register twice by accident.
  private handlers = new Map<string, Set<(payload: unknown) => void>>()

  on<K extends keyof EventMap>(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 tears down.
    // No off() method to forget. No memory leaks.
    return () => this.handlers.get(event)?.delete(handler as (payload: unknown) => void)
  }

  emit<K extends keyof EventMap>(event: K, payload: EventMap[K]) {
    // Every handler for this event fires. None know about each other.
    this.handlers.get(event)?.forEach(h => h(payload))
  }
}

// One bus, shared across the whole process via a single import.
export const bus = new EventBus()
export type { EventMap }

A publisher looks like this — OrderService emitting without knowing who listens:

import { bus } from '../bus/EventBus'

export function placeOrder(customerId: string, total: number) {
  const orderId = `ORD-${String(orderSeq++).padStart(3, '0')}`

  // This one line triggers every subscribed service.
  // OrderService has no import of InventoryService, EmailService, or PaymentService.
  // It literally does not know they exist. That is decoupling.
  bus.emit('order.created', { orderId, customerId, total })
  return orderId
}

Live sandbox: Run this in StackBlitz — five services, zero direct calls between them. Add a new bus.on() listener in any service file, save, and watch your handler fire without touching anything else. That is the point.

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.

// Both the domain change and the event write happen in one transaction.
// If the process crashes between them, both roll back. Nothing is lost.
// Nothing is partially applied.
async function createOrder(orderId: string, customerId: string, total: number) {
  await db.transaction(async (trx) => {
    await trx('orders').insert({ id: orderId, customer_id: customerId, total })
    await trx('events').insert({
      type: 'order.created',
      payload: { orderId, customerId, total },
    })
  })
}

// Background consumer — runs on a cron or setInterval.
// FOR UPDATE SKIP LOCKED means multiple consumers can run in parallel
// without stepping on each other. Locked rows are skipped, not blocked.
async function processEvents() {
  const events = await db.raw(`
    SELECT * FROM events
    WHERE processed = false
    ORDER BY occurred_at
    LIMIT 20
    FOR UPDATE SKIP LOCKED
  `)

  for (const ev of events.rows) {
    try {
      await handle(ev)
      await db('events').where({ id: ev.id }).update({ processed: true })
    } catch {
      // Do not mark processed — let the next poll retry it.
    }
  }
}

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.