Building Event-Driven Architecture with Inngest

Series Background: This is Part 3 of the Portfolio series. . Following the initial build and security hardening, here we explore how event-driven architecture transforms user experience and system reliability using Inngest for background job processing.

Your API routes are lying to your users. They return 200 OK while work is still happening. The contact form says “Message sent!” but the email hasn’t been delivered yet.

Event-driven architecture fixes this by separating acknowledgment from processing. Users get instant feedback. Work happens reliably in the background. Here’s how Inngest makes this practical for any Next.js project.

// The old way: synchronous processing
export async function POST(request: NextRequest) {
  const { name, email, message } = await request.json();
 
  // User waits 1-2 seconds for this...
  await resend.emails.send({
    from: FROM_EMAIL,
    to: AUTHOR_EMAIL,
    subject: `Contact form: ${name}`,
    text: message,
  });
 
  // Only then do they see success
  return NextResponse.json({ success: true });
}

Event-Driven Architecture Explained

separates two concerns:

1. Acknowledging the request (fast, synchronous)
2. Processing the work (async, can be slow, can retry)

Before (Synchronous):
User → API Route → Email Service → Response
         └─────── 1-2 seconds ──────┘
 
After (Event-Driven):
User → API Route → Queue Event → Response (< 100ms)
                        ↓
              Background Function → Email Service
                        └─── Retries if needed ───┘

Modern event-driven systems add steps: discrete, named operations with checkpoints. If step 3 fails, steps 1 and 2 don’t re-run. This durable execution transforms reliability thinking.

Further Reading: For comprehensive overviews of event-driven architecture patterns, see Martin Fowler’s Event-Driven Architecture and AWS’s What is Event-Driven Architecture?

Implementation: Contact Form

Here’s the actual production code from this portfolio:

Step 1: Queue Event from API Route

// src/app/api/contact/route.ts
import { inngest } from '@/inngest/client';
 
export async function POST(request: NextRequest) {
  const { name, email, message } = await request.json();
 
  // Validate and sanitize inputs...
 
  // Queue the event (returns immediately)
  await inngest.send({
    name

The API route now completes in under 100ms. The user sees instant feedback.

Step 2: Handle Event in Background Function

// src/inngest/contact-functions.ts
import { inngest } from './client';
import { Resend } from 'resend';
import { track } from '@vercel/analytics/server';
 
export const contactFormSubmitted = inngest.createFunction(
  {
    id: 'contact-form-submitted',
    retries: 3, // Automatic retries with exponential backoff

Why Steps Matter

Each step.run() creates a checkpoint. If Step 2 fails:

• Step 1 doesn’t re-run (notification already sent)
• Only Step 2 retries
• You see exactly where it failed in the Inngest dashboard

This is durable execution: your function survives failures and resumes from the last successful step.

Scheduled Tasks: GitHub Contributions

Event-driven architecture isn’t just for user actions. Scheduled tasks benefit too.

The homepage shows a GitHub contribution heatmap. Instead of fetching on every page load (slow, rate-limited), I pre-populate the cache hourly:

// src/inngest/github-functions.ts
export const refreshGitHubData = inngest.createFunction(
  {
    id: 'refresh-github-data',
    retries: 1, // Fail fast on hourly jobs
  },
  { cron: '0 * * * *' }, // Every hour at minute 0
  async ({ step }) => {
    await step.run('fetch-github-contributions', async ()

Benefits:

• Page loads are instant (data is pre-cached)
• GitHub API rate limits aren’t a concern
• Failures don’t affect users (stale cache is served)
• Full observability in the Inngest dashboard

Production Functions in This Portfolio

Here’s what’s actually running right now:

The Security Monitor

After discovering a critical React vulnerability (React2Shell) in December 2025 (with a 13-hour detection gap), I added automated security monitoring.

export const securityAdvisoryMonitor = inngest.createFunction(
  {
    id: 'security-advisory-monitor',
    retries: 3,
  },
  { cron: '0 0,8,16 * * *' }, // 3x daily (00:00, 08:00, 16:00 UTC)
  async ({ step }) => {
    // Step 1: Fetch advisories from GHSA
    const advisories = await step.run('fetch-ghsa-advisories'

Blog Analytics

The blog tracks views and automatically detects milestones:

export const trackPostView = inngest.createFunction(
  { id: 'track-post-view' },
  { event: 'blog/post.viewed' },
  async ({ event, step }) => {
    const { postId, slug, title } = event.data;
 
    await step.

Developer Experience

Local Development

Inngest provides a local dev server with a powerful UI:

npx inngest-cli@latest dev

This gives you:

• Real-time function execution logs
• Ability to trigger events manually
• Step-by-step execution visualization
• Replay failed functions from any step

Testing

Functions are async functions; test them like any other code:

describe('contactFormSubmitted', () => {
  it('sends notification and confirmation emails', async () => {
    const mockEvent = {
      data: {
        name: 'Test User',
        email: 'test@example.com',
        message: 'Hello!',
        submittedAt: new Date().toISOString(),

Deployment

Inngest integrates with Vercel in a few steps:

1. Install the Vercel integration in your Inngest dashboard

2. Export functions from a single endpoint:

// src/app/api/inngest/route.ts
import { serve } from 'inngest/next';
import { inngest } from '@/inngest/client';
import { contactFormSubmitted } from '@/inngest/contact-functions';
import { refreshGitHubData } from '@/inngest/github-functions';
import { trackPostView, calculateTrending } from '@/inngest/blog-functions';
import { securityAdvisoryMonitor 

3. Deploy. Inngest discovers your functions automatically

Environment variables (INNGEST_EVENT_KEY, INNGEST_SIGNING_KEY) are set automatically by the Vercel integration.

Results

After migrating to event-driven architecture (measured in this portfolio’s production environment):

Note: These metrics reflect this specific implementation. Your results may vary based on network conditions, third-party API performance, and deployment region.

Key Takeaways

1. Decouple acknowledgment from processing: users want fast feedback, not fast completion
2. Steps create checkpoints: failed steps retry without re-running successful ones
3. Scheduled tasks benefit too: pre-populate caches, monitor systems, aggregate data
4. Local dev matters: Inngest’s dev UI makes debugging enjoyable
5. Start simple: you don’t need event-driven for everything

Event-driven architecture doesn’t require enterprise scale. With tools like Inngest, any Next.js project can benefit from reliable background processing, instant API responses, and better observability.

When NOT to Use Event-Driven

Event-driven architecture isn’t always the answer:

• Simple CRUD: Reading/writing to a database doesn’t need queuing. Saving a user preference? Just write to the database directly.
• Real-time requirements: If users need the result immediately, don’t defer it. A “Reply to comment” feature where users expect to see their comment appear instantly should stay synchronous, even if it takes 500ms.
• Debugging complexity: More moving parts means more places to look. If your team is already stretched thin, the observability benefits might not outweigh the learning curve.
• Small scale: If you have 10 users/day, synchronous is simpler. Don’t add infrastructure complexity you don’t need yet.

The rule of thumb: if users don’t need to wait for the result, don’t make them wait. But if they do need to see the result immediately, don’t hide it behind a queue.

Background jobs are a security surface. The security monitor exists because CVE detection gaps matter. If processing sensitive data, apply the same rigor you would to API routes: validate inputs, sanitize outputs, monitor for anomalies.

Resources

• Inngest Documentation
• Inngest + Vercel Integration
• Durable Execution Explained
• Part 1: Shipping a Developer Portfolio
• Part 2: Hardening a Developer Portfolio

What sold me on Inngest:

1. Zero infrastructure: No Redis queue to manage
2. Local development: Beautiful dev UI for testing functions
3. Automatic retries: Configurable retry policies with exponential backoff
4. Step functions: Break complex workflows into observable, resumable steps
5. Vercel-native: First-class integration, deploys automatically

When a post hits 1,000 views, I get notified. The trending calculation runs hourly, scoring posts by recent activity to surface what readers are finding valuable.