DEV Community: Ankit Halder

Building an Event-Driven Restaurant System with Node.js and Kafka

Ankit Halder — Sat, 19 Sep 2026 11:56:11 +0000

🔗 Source Code: View on GitHub

Have you ever wondered how food delivery apps handle thousands of orders, notifications, and billing processes simultaneously? The secret lies in Event-Driven Architecture (EDA).

In this article, I'll walk you through a simple yet powerful CLI application that simulates a restaurant's order management system using Node.js and Apache Kafka.

Why Kafka for a Restaurant System?

When a customer places an order, multiple things need to happen:

The Billing service needs to process the payment.
The Notification service needs to send updates to the user.
The Rider service needs to assign a delivery partner once the food is ready.

Instead of having a monolithic app where each component calls the other synchronously (which can lead to bottlenecks), we can use Kafka. The central system simply announces, "Hey, a new order was placed!" or "The order is ready!" The respective services listen for these events and act independently.

The Architecture Diagram

Here is a visual representation of how our services interact with Kafka topics:

flowchart LR
    %% Producer
    P[Restaurant CLI Producer]

    %% Topics (Kafka)
    subgraph Kafka [Kafka Cluster]
        T1[(Topic: new-order)]
        T2[(Topic: order-accepted)]
        T3[(Topic: order-ready)]
    end

    %% Consumers
    C_Billing[Billing Consumer]
    C_Notif[Notification Consumer]
    C_Rider[Rider Consumer]

    %% Producer pushing to Topics
    P -- Publishes --> T1
    P -- Publishes --> T2
    P -- Publishes --> T3

    %% Consumers subscribing from Topics
    T1 -. Subscribes .-> C_Billing
    T1 -. Subscribes .-> C_Notif
    T2 -. Subscribes .-> C_Notif
    T3 -. Subscribes .-> C_Rider
    T3 -. Subscribes .-> C_Notif

As shown above:

The Billing service only cares about the new-order events.
The Rider service only springs into action when an order-ready event occurs.
The Notification service is the nosy one—it tracks the order at every step (new-order, order-accepted, and order-ready) to keep the customer updated!

Code Explanation

Let's dive into the core of how this is implemented using kafkajs.

1. Kafka Initialization and Admin Client

Before producing or consuming, we ensure our required topics exist. The init() function uses the Kafka Admin Client to check for and dynamically create topics (new-order, order-accepted, order-ready) if they don't already exist.

const admin = kafka.admin();
await admin.connect();
const existing = await admin.listTopics();
// ... logic to create missing topics ...
await admin.createTopics({ topics: events_to_be_created });

2. The Producer

The Producer takes interactive input from the user (via Node's readline module) and produces events based on the user's actions. When a new order is created, or its status changes, we push a message to the relevant Kafka topic.

const producer = kafka.producer();
await producer.connect();
await producer.send({
    topic: topic,
    messages: [
        {
            partition: partition,
            value: JSON.stringify(data),
        },
    ],
});

We assign events to different partitions dynamically (e.g., orders.length % 2) to demonstrate distributing the load.

3. The Consumers (Service Subscriptions)

We define multiple consumers using different groupIds to simulate independent microservices.

Billing Service: Uses groupId: 'billing' and subscribes strictly to new-order.
Rider Service: Uses groupId: 'rider' and subscribes to order-ready.
Notification Service: Uses groupId: 'notification' and subscribes to multiple topics: ['new-order', 'order-accepted', 'order-ready'].

const riderConsumer = kafka.consumer({ groupId: 'rider' });
await riderConsumer.connect();
await riderConsumer.subscribe({ topics: ['order-ready'], fromBeginning: true });
await riderConsumer.run({
    eachMessage: async ({ topic, partition, message }) => {
        console.log(`[RIDER] Received on ${topic}: ${message.value.toString()}`);
    },
});

By assigning distinct Consumer Groups, Kafka guarantees that each microservice independently receives and processes the events it cares about.

How to Run the Project

Want to try it out yourself? Follow these steps to get the restaurant system running on your local machine.

Prerequisites

Docker installed and running.
Node.js installed.

Setup Instructions

Clone and navigate to the project directory: Navigate into the restaurant-kafka-cli folder.

   cd restaurant-kafka-cli

Start the Kafka Cluster: We have included a docker-compose.yml file to quickly spin up an Apache Kafka instance.

   docker-compose up -d

Install Dependencies: Install the required Node.js packages (primarily kafkajs).

   npm install

Run the Application: Since this is a CLI-based application, it is best to open at least two separate terminal windows.

In Terminal 1 (The Consumer):

   node main.js

Select option 2. Consumer when prompted. This will start the Rider, Billing, and Notification consumers in the background, listening for events.

In Terminal 2 (The Producer):

   node main.js

Select option 1. Producer when prompted. This will start the interactive CLI where you can create new orders, accept them, and mark them as ready.

Play around! In the Producer terminal, create an order (e.g., 2/101/Pizza/500). Then watch the magic happen in the Consumer terminal as the different services independently pick up the events and process them!

Wrapping Up

By decoupling our services using Kafka, we've built a highly scalable foundation. If the billing service goes down, the restaurant can still accept orders. If we want to add a new "Analytics" service, we just plug in another consumer to listen to the topics—no changes needed to the existing codebase!

That's the beauty of Event-Driven Architecture. Happy coding! 🚀

Building an MVP Agentic Tool-Use Bot with Node.js and OpenRouter 🌤️🤖

Ankit Halder — Tue, 08 Sep 2026 05:12:20 +0000

Have you ever wanted to build your own ChatGPT-like interface that can actually do things? Today, we're going to break down Mausam AI, a chatbot built with Node.js that can check real-time weather, temperature, and humidity for any city.

⚠️ Disclaimer: This project is an MVP (Minimum Viable Product). It is not a production-ready application. Instead, it serves as a conceptual demonstration of an Agentic Tool-Use architecture.

🔗 GitHub Repository: [https://github.com/OriginalAnkit/ai-rag-mausam-ai]

Screen shot of Mausam AI

Let's dive into how the code works!

What is Agentic Tool-Use and Why Do We Need It?

To understand why tool-use is so important, we first need to understand a massive limitation of Large Language Models (LLMs):

Trained models don't have real-time data.
An LLM's knowledge is frozen in time based on when it was trained. If you ask a standard, isolated model, "What is the weather in Mumbai right now?", it will either hallucinate a random answer or apologize, stating that it cannot browse the live internet.

This is where Agentic workflows come in.
Instead of relying solely on the LLM's static internal memory, we give the LLM a tool (get_mausam) that it can call to fetch the live, real-time weather report from an external API (wttr.in). We then inject that live data straight back into the conversation context so the LLM can generate an accurate, up-to-the-minute response!

1. The Brains: System Prompts and Agent Logic

The magic of this bot lives in helper.js. Instead of just asking the LLM to write text, we force the LLM to think in a structured loop: START ➡️ PLAN ➡️ TOOL ➡️ OUTPUT.

We achieve this using a strict system prompt and forcing the response format to JSON.

const MAIN_SYSTEM_PROMPT = `
You are an AI agent that reply only to queries related to weather, temperate and humidity.

STRICT RULES:
- output must a single valid json without any extra space, text. NO markdown , No Text, No output tags.
- MUST run one step at a time. Do not run multiple steps in parallel. Stop after each step
- Strictly follow the Sequence of steps must be START then PLAN then TOOL then OUTPUT
- don't run a step more than once for a single query.

OUTPUT FORMAT:
{
    "step": START|PLAN|TOOL|OUTPUT,
    "context": "string",
    "input": "string",
    "usefull": "boolean",
    "toolname": "string"
}

AVAILABLE TOOL:
- get_mausam -> return temperate, weather and humidity for a given location
`;

By enforcing this structure, our backend can read the JSON step by step. If the AI decides it needs to use a tool, it outputs {"step": "TOOL", "toolname": "get_mausam", "input": "Mumbai"}.

Executing the Loop Safely

Our backend intercepts this and executes the tool on behalf of the AI. To prevent infinite loops or hallucinations, we wrap it in a strict MAX_ITERATIONS check with proper error boundaries:

const getConversation = async function (messages, context = []) { 
    let iterations = 0;
    const MAX_ITERATIONS = 5;

    while (iterations < MAX_ITERATIONS) {
        iterations++;
        try {
            const completion = await callOpenRouterModel(messages);
            let outputContent = completion?.choices[0]?.message?.content;

            // ... Parse JSON Output Safely ...

            if (output.step === "OUTPUT") {
                // The AI has the final answer
                context.push({ sender: "SYSTEM", message: output.context });
                return;
            } else if (output.step === "TOOL" && output.toolname === "get_mausam") {
                 // The AI requested a tool. We fetch the data and feed it back!
                 let tool_resp = await getWeather(output.input);
                 messages.push({ role: "system", content: \`RESPONSE FROM get_mausam: \${tool_resp}\` });
            } else {
                 // Intermediate thinking steps (START, PLAN)
                 context.push({ sender: "BOT", message: (output.context || 'Thinking') + '...' });
                 messages.push({ role: "system", content: outputContent });
            }
            await sleep(1000); // 1-second safety delay to prevent spamming
        } catch (error) {
            console.error("Agent loop error:", error.message);
            context.push({ sender: "SYSTEM", message: "An error occurred while processing your request." });
            return;
        }
    }
}

2. The Tool: Fetching Weather Data

When the AI calls get_mausam, it triggers a simple JavaScript fetch to wttr.in, an amazing console-oriented weather forecasting service.

async function getWeather(city) {
    const url = \`https://wttr.in/\${encodeURIComponent(city)}?format=%c+%C+%t+%h+%T\`;

    const response = await fetch(url);
    if (!response.ok) throw new Error(\`Request failed\`);

    const data = await response.text(); 
    return data.trim(); // Returns e.g., "☀️ Clear +22°C 45%"
}

3. Resilient API Calls

To keep our MVP robust against API key exhaustion, we built a fallback mechanism when calling OpenRouter. We use try/catch to attempt the primary key, and automatically fail over to a backup client if an error is thrown.

const client1 = new OpenAI({ baseURL: "https://openrouter.ai/api/v1", apiKey: process.env.API_KEY });
const client2 = new OpenAI({ baseURL: "https://openrouter.ai/api/v1", apiKey: process.env.OPEN_ROUTER_KEY_2 });

const callOpenRouterModel = async function (messages) {
    const requestPayload = {
        model: "liquid/lfm-2.5-2.6b:free",
        messages: messages,
        response_format: { type: "json_object" }
    };

    try {
        return await client1.chat.completions.create(requestPayload);
    } catch (error) {
        console.error("Primary key failed, trying fallback...", error.message);
        return await client2.chat.completions.create(requestPayload);
    }
}

4. The Express Backend & Chat UI

We wrap this entire logic inside a simple Express.js server (app.js). To support multiple users concurrently without race conditions, we store chat states in a sessions map, indexed by a unique sessionId generated on the frontend.

On the frontend (index.ejs), we have a sleek dark-mode UI that generates the sessionId via sessionStorage and polls the GET /messages?sessionId=... endpoint every second to stream in the AI's thoughts.

We even styled the intermediate "thinking" steps differently than the final answer so users can peek into the AI's reasoning without it being visually distracting!

Conclusion

Building Agentic pipelines doesn't require massive frameworks. By enforcing JSON schemas and writing a simple while loop, you can give LLMs access to the outside world.

Feel free to check out the GitHub repo and tinker with it yourself!