Building an AI-Powered Chatbot for Multi-Tenant POS Systems: A Microservices Journey

A Developer's Story of Integration, Isolation, and Intelligence

Hey there! 👋

I want to share something exciting I built that transformed how business owners interact with their POS systems. You know those moments when a restaurant owner asks, "What were my sales yesterday?" or "Which menu item is performing best?" Usually, they'd need to navigate through multiple dashboards, export reports, or worse - manually calculate things.

What if they could just... ask?

That's exactly what I built — an AI-powered chatbot that seamlessly integrates with a microservices architecture, providing real-time business insights through natural language conversations. And the best part? It maintains complete tenant isolation while orchestrating data from five different services.

Let me show you what I learned along the way.

⚡ Quick Start (TL;DR)

For developers building similar systems:

Architecture Pattern:

Chatbot Service (Express + TypeScript + Redis)
├── AI Layer (GitHub Models GPT-4o)
├── Integration Layer (5 Microservices)
│   ├── Auth Service (JWT Validation)
│   ├── POS Core (Orders & Sales)
│   ├── Inventory Service (Stock Data)
│   ├── Payment Service (Transactions)
│   └── Restaurant Service (Store Operations)
└── Session Management (Redis with TTL)

Key Features:

• 🤖 Natural language interface with bilingual support (English/Myanmar)

• 🔒 Multi-tenant isolation at every layer

• 📊 Real-time analytics aggregation from multiple services

• 💬 Persistent chat sessions with context awareness

• 🚀 Rate limiting and resource protection

That's it! Let's dive into how this all works.

🤔 The Problem: Data Silos in Microservices

Think about your typical microservices architecture. You've got:

1. POS Core Service - handling orders and transactions

2. Inventory Service - managing stock levels

3. Payment Service - processing payments

4. Restaurant Service - store operations and menu items

5. Auth Service - user management and authentication

Each service does its job perfectly. But here's the challenge:

How do you give business owners a unified view without them needing to know which service holds what data?

Before the chatbot:

Owner: "What were my sales yesterday?"
You: "Let me check... 
      - Log into dashboard
      - Navigate to reports
      - Select date range
      - Export data
      - Manually calculate totals"
Owner: *waits 5 minutes*

With the chatbot:

Owner: "What were my sales yesterday?"
Chatbot: *automatically queries POS Core, aggregates data*
Chatbot: "Your sales yesterday were MMK 1,234,567 from 89 orders. 
         Your top-selling item was Fried Rice (23 orders, MMK 345,000)"
Owner: *happy in 3 seconds*

No context switching. No manual calculations. No friction.

This is what we're building towards, and it's available today.

🏗️ Architecture Deep Dive

The Core Components

// Service Structure
Chatbot Service (Port 4006)
├── AI Service (OpenAI-compatible API)
│   ├── GitHub Models (gpt-4o via Azure)
│   └── Context-aware prompt engineering
├── Analytics Service
│   ├── POS Core Integration (Sales Data)
│   ├── Inventory Integration (Stock Levels)
│   └── Payment Integration (Transaction Details)
├── Restaurant Service Integration
│   ├── Store Orders & Status
│   ├── Menu Items Performance
│   └── Table Analytics
├── Session Management (Redis)
│   ├── 1-hour TTL per session
│   ├── Max 50 messages per session
│   └── Automatic cleanup
└── Tenant Isolation Middleware
    ├── JWT token validation
    ├── x-tenant-id header injection
    └── Per-tenant rate limiting

Architecture Diagram

Technology Stack Choices

Why Express + TypeScript?

• Type safety for service integration contracts

• Familiar ecosystem for rapid development

• Excellent middleware support for cross-cutting concerns

Why Redis for Sessions?

• In-memory speed for chat context retrieval

• Built-in TTL for automatic session cleanup

• Atomic operations for concurrent access

Why GitHub Models (GPT-4o)?

• OpenAI-compatible API (easy migration)

• Enterprise-grade reliability through Azure

• Generous token limits for complex queries

🔌 Integration Patterns: How Services Talk

Pattern 1: Service-to-Service Authentication

Every microservice call needs authentication. Here's how we handle it:

// Authentication Middleware
export interface AuthRequest extends Request {
  user?: {
    id: string;
    tenantId: string;
    email: string;
    role: string;
  };
}

export const authenticateToken = (
  req: AuthRequest,
  res: Response,
  next: NextFunction
): void => {
  const authHeader = req.headers['authorization'];
  const token = authHeader && authHeader.split(' ')[1];

  if (!token) {
    res.status(401).json({ error: 'Access token required' });
    return;
  }

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET) as any;
    
    req.user = {
      id: decoded.id || decoded.userId,
      tenantId: decoded.tenantId,
      email: decoded.email,
      role: decoded.role
    };

    // Critical: Inject tenant ID for downstream services
    req.headers['x-tenant-id'] = req.user.tenantId;

    next();
  } catch (error) {
    res.status(403).json({ error: 'Invalid or expired token' });
  }
};

Key Learning: The x-tenant-id header injection is crucial. It ensures every downstream service call automatically includes tenant context.

Pattern 2: Intelligent Data Aggregation

When a user asks "What were my sales yesterday?", the chatbot needs to:

1. Understand the intent (sales query with time range)

2. Fetch data from POS Core Service

3. Aggregate and calculate metrics

4. Format the response naturally

Here's how we do it:

// Analytics Service - Orchestrating Multiple Data Sources
export class AnalyticsService {
  private posCoreServiceUrl: string;
  private inventoryServiceUrl: string;

  private getHeaders(tenantId: string, token?: string): any {
    return {
      'x-tenant-id': tenantId,
      'Authorization': token ? `Bearer ${token}` : undefined
    };
  }

  async getSalesAnalytics(
    tenantId: string,
    startDate: Date,
    endDate: Date,
    token?: string
  ): Promise<SalesAnalytics> {
    const headers = this.getHeaders(tenantId, token);

    // Fetch orders from POS Core
    const ordersResponse = await axios.get(
      `${this.posCoreServiceUrl}/api/orders`,
      {
        headers,
        params: {
          startDate: startDate.toISOString(),
          endDate: endDate.toISOString(),
          tenantId
        }
      }
    );

    const orders = ordersResponse.data.orders || [];

    // Calculate analytics on the fly
    const totalRevenue = orders.reduce((sum: number, order: any) => 
      sum + (parseFloat(order.total) || 0), 0
    );

    const totalOrders = orders.length;
    const averageOrderValue = totalOrders > 0 ? totalRevenue / totalOrders : 0;

    // Payment method breakdown
    const paymentMethods: any = {};
    orders.forEach((order: any) => {
      const method = order.paymentMethod || 'UNKNOWN';
      paymentMethods[method] = (paymentMethods[method] || 0) + 1;
    });

    // Top products analysis
    const productCounts: any = {};
    orders.forEach((order: any) => {
      if (order.items) {
        order.items.forEach((item: any) => {
          const productName = item.nameEn || item.name || 'Unknown';
          if (!productCounts[productName]) {
            productCounts[productName] = { name: productName, quantity: 0, revenue: 0 };
          }
          productCounts[productName].quantity += item.quantity || 0;
          productCounts[productName].revenue += parseFloat(item.total || 0);
        });
      }
    });

    const topProducts = Object.values(productCounts)
      .sort((a: any, b: any) => b.revenue - a.revenue)
      .slice(0, 5);

    return {
      totalRevenue,
      totalOrders,
      averageOrderValue,
      topProducts,
      paymentMethodBreakdown: paymentMethods,
      period: `${format(startDate, 'yyyy-MM-dd')} to ${format(endDate, 'yyyy-MM-dd')}`
    };
  }
}

Key Learning: Don't try to build a separate analytics database initially. Aggregate on-demand for faster iteration. Optimize later if performance becomes an issue.

Pattern 3: Restaurant Service Integration

For store-specific operations (orders, menu items, tables), we integrate with the Restaurant Service:

export class RestaurantService {
  private restaurantServiceUrl: string;

  async getOrderStats(
    tenantId: string,
    startDate?: Date,
    endDate?: Date,
    token?: string
  ): Promise<StoreOrderStats> {
    const headers = this.getHeaders(tenantId, token);

    const params: any = {};
    if (startDate) params.startDate = startDate.toISOString();
    if (endDate) params.endDate = endDate.toISOString();

    const response = await axios.get(
      `${this.restaurantServiceUrl}/api/restaurant/orders/stats`,
      { headers, params }
    );

    const data = response.data.data;

    return {
      totalOrders: data.totalOrders || 0,
      pendingOrders: data.pendingOrders || 0,
      approvedOrders: data.approvedOrders || 0,
      readyOrders: data.readyOrders || 0,
      completedOrders: data.completedOrders || 0,
      cancelledOrders: data.cancelledOrders || 0,
      totalRevenue: parseFloat(data.totalRevenue) || 0,
      period: startDate && endDate
        ? `${format(startDate, 'yyyy-MM-dd')} to ${format(endDate, 'yyyy-MM-dd')}`
        : 'All time'
    };
  }
}

Key Learning: Each service integration follows the same pattern: headers with tenant context, error handling, and data transformation.

🤖 The AI Layer: Making It Conversational

Context-Aware Prompt Engineering

The magic happens in how we construct the AI's context. Here's the system prompt:

private buildSystemPrompt(context: any): string {
  return `You are an AI assistant for a POS System. 
You help business owners analyze their sales data and answer questions 
about their business performance.

**Language Support:**
- You MUST support both English and Myanmar (Burmese) language
- Detect the user's language from their message
- Respond in the SAME language the user uses

**Your Capabilities:**
- Access POS Reports (sales, products, payments, inventory)
- Access Store/Restaurant Reports (orders, menu items, tables)
- Provide sales analytics (daily, weekly, monthly)
- Answer questions about orders, revenue, and transactions
- Analyze product performance and inventory
- Track real-time restaurant operations
- Monitor checkout and payment breakdown
- Give business insights and recommendations

**Available Data Context:**
${JSON.stringify(context, null, 2)}

**Important Rules:**
1. ALWAYS respond in the user's language (Myanmar or English)
2. Only discuss data for the current tenant (business)
3. Provide accurate numbers based on the context
4. If data is not available, clearly state that
5. Be concise and professional
6. Format currency amounts clearly (e.g., "MMK 1,234")
7. Use proper date formats
8. Suggest specific actions when appropriate`;
}

Key Learning: Injecting the actual data context into the prompt allows the AI to give specific, accurate answers rather than generic responses.

Intent Analysis and Dynamic Data Fetching

async sendMessage(req: AuthRequest, res: Response): Promise<void> {
  const { sessionId, message } = req.body;

  // Save user message
  await sessionService.saveMessage(sessionId, {
    role: 'user',
    content: message,
    timestamp: new Date()
  });

  // Analyze user query to determine intent
  const analysis = await aiService.analyzeQuery(message);

  // Fetch relevant data based on intent
  let contextData: any = {};

  if (analysis.intent === 'sales_query') {
    contextData.sales = await analyticsService.getSalesAnalytics(
      req.user.tenantId,
      analysis.timeRange.start,
      analysis.timeRange.end,
      req.headers.authorization?.split(' ')[1]
    );
  }

  if (analysis.intent === 'inventory_query') {
    contextData.inventory = await analyticsService.getInventoryStats(
      req.user.tenantId,
      req.headers.authorization?.split(' ')[1]
    );
  }

  if (analysis.intent === 'store_orders_query') {
    contextData.storeOrders = await restaurantService.getOrderStats(
      req.user.tenantId,
      analysis.timeRange?.start,
      analysis.timeRange?.end,
      req.headers.authorization?.split(' ')[1]
    );
  }

  // Get chat history for context
  const history = await sessionService.getMessages(sessionId);

  // Generate AI response with full context
  const aiResponse = await aiService.generateResponse(
    message,
    contextData,
    history
  );

  // Save AI response
  await sessionService.saveMessage(sessionId, {
    role: 'assistant',
    content: aiResponse.message,
    timestamp: new Date()
  });

  res.json({
    success: true,
    message: aiResponse.message,
    context: contextData,
    usage: aiResponse.usage
  });
}

Key Learning: The intent analysis step is crucial. It determines which services to call, preventing unnecessary API requests and reducing latency.

Intent Analysis Decision Flow

🔒 Tenant Isolation: The Non-Negotiable

In a multi-tenant system, data leakage is catastrophic. Here's how we ensure isolation at every layer:

Layer 1: Authentication Middleware

// Every request requires a valid JWT with tenantId
export const authenticateToken = (req: AuthRequest, res: Response, next: NextFunction) => {
  const token = req.headers['authorization']?.split(' ')[1];
  const decoded = jwt.verify(token, process.env.JWT_SECRET);
  req.user = {
    id: decoded.id,
    tenantId: decoded.tenantId, // ← Critical
    email: decoded.email,
    role: decoded.role
  };
  req.headers['x-tenant-id'] = req.user.tenantId; // ← Inject for downstream
  next();
};

Layer 2: Service Integration

// Every service call includes tenant context
private getHeaders(tenantId: string, token?: string): any {
  return {
    'x-tenant-id': tenantId, // ← Tenant isolation
    'Authorization': token ? `Bearer ${token}` : undefined
  };
}

Layer 3: Session Management

// Session keys include tenant ID
async createSession(tenantId: string, userId: string): Promise<ChatSession> {
  const sessionId = uuidv4();
  const sessionKey = `chat:${tenantId}:${sessionId}`; // ← Tenant prefix
  
  await redisClient.setEx(
    sessionKey,
    SESSION_TTL,
    JSON.stringify(session)
  );
  
  return session;
}

// Validate session belongs to tenant
async validateSessionTenant(sessionId: string, tenantId: string): Promise<boolean> {
  const sessionKey = `chat:${tenantId}:${sessionId}`;
  const session = await redisClient.get(sessionKey);
  return session !== null;
}

Key Learning: Tenant isolation must be enforced at every layer. Never trust client-provided tenant IDs — always extract from verified JWT tokens.

💬 Session Management: Keeping Context

Chat sessions need to maintain context across multiple messages. Here's how we handle it:

export class SessionService {
  async createSession(tenantId: string, userId: string): Promise<ChatSession> {
    const sessionId = uuidv4();
    const session: ChatSession = {
      sessionId,
      tenantId,
      userId,
      messages: [],
      createdAt: new Date(),
      updatedAt: new Date()
    };

    // Store in Redis with 1-hour TTL
    const sessionKey = `chat:${tenantId}:${sessionId}`;
    await redisClient.setEx(
      sessionKey,
      3600, // 1 hour
      JSON.stringify(session)
    );

    return session;
  }

  async saveMessage(sessionId: string, message: ChatMessage): Promise<void> {
    const session = await this.getSession(sessionId);
    
    session.messages.push(message);
    session.updatedAt = new Date();

    // Keep only last 50 messages to prevent memory bloat
    if (session.messages.length > 50) {
      session.messages = session.messages.slice(-50);
    }

    const sessionKey = `chat:${session.tenantId}:${sessionId}`;
    await redisClient.setEx(
      sessionKey,
      3600,
      JSON.stringify(session)
    );
  }

  async getMessages(sessionId: string): Promise<ChatMessage[]> {
    const session = await this.getSession(sessionId);
    // Return last 10 messages for AI context (balance between context and token usage)
    return session.messages.slice(-10);
  }
}

Key Learning: Balance between context richness and resource usage. 10 messages provide enough context without overwhelming the AI or consuming excessive tokens.

🚦 Rate Limiting: Protecting Resources

AI API calls are expensive. Rate limiting prevents abuse:

import rateLimit from 'express-rate-limit';

export const createRateLimiter = () => {
  return rateLimit({
    windowMs: 60 * 1000, // 1 minute
    max: 30, // 30 requests per minute
    message: 'Too many requests, please try again later',
    standardHeaders: true,
    legacyHeaders: false,
    // Use tenant ID for rate limiting
    keyGenerator: (req: AuthRequest) => {
      return req.user?.tenantId || req.ip;
    }
  });
};

Key Learning: Rate limit by tenant ID, not IP address. Multiple users from the same organization (same IP) shouldn't be penalized, but a single tenant shouldn't monopolize resources.

🔄 The Request Flow: Putting It All Together

Let's trace a complete request:

1. User: "What were my sales yesterday?"
   ↓
2. Frontend → POST /api/chat/message
   { sessionId, message, Authorization: Bearer <jwt> }
   ↓
3. Auth Middleware
   - Validates JWT token
   - Extracts tenantId: "tenant-123"
   - Injects x-tenant-id header
   ↓
4. Rate Limiter
   - Checks: tenant-123 → 15/30 requests used
   - Allows: ✅
   ↓
5. Session Validation
   - Verifies: chat:tenant-123:session-456 exists
   - Allows: ✅
   ↓
6. Intent Analysis
   - Detects: sales_query
   - Time range: yesterday
   ↓
7. Data Fetching (Parallel)
   → POS Core: GET /api/orders
     Headers: { x-tenant-id: tenant-123, Authorization: Bearer <jwt> }
     Params: { startDate: 2025-12-05, endDate: 2025-12-05 }
   ← Response: { orders: [...89 orders...] }
   ↓
8. Analytics Calculation
   - Total Revenue: MMK 1,234,567
   - Total Orders: 89
   - Top Product: Fried Rice (23 orders)
   ↓
9. AI Generation
   - System Prompt + Context Data + Chat History
   → GitHub Models API: POST /chat/completions
   ← Response: Natural language summary
   ↓
10. Session Update
    - Save user message + AI response
    - Update session timestamp
    ↓
11. Response to Frontend
    {
      success: true,
      message: "Your sales yesterday were MMK 1,234,567...",
      context: { sales: {...} },
      usage: { totalTokens: 842 }
    }

Total Latency: ~2-3 seconds (primarily AI generation)

Complete Request Flow Sequence

🌍 Bilingual Support: A Technical Challenge

Supporting English and Myanmar (Burmese) required special considerations:

Challenge 1: Language Detection

async analyzeQuery(userMessage: string): Promise<{
  intent: string;
  entities: any;
  timeRange?: { start: Date; end: Date };
}> {
  const message = userMessage.toLowerCase();
  
  // Detect Myanmar language (Unicode range: U+1000 to U+109F)
  const isMyanmarText = /[\u1000-\u109F]/.test(userMessage);
  
  // Intent detection works in both languages
  if (message.includes('sales') || message.includes('အရောင်း')) {
    return { intent: 'sales_query', entities: {} };
  }
  
  if (message.includes('inventory') || message.includes('စာရင်း')) {
    return { intent: 'inventory_query', entities: {} };
  }
  
  // ... more intent patterns
}

Challenge 2: Consistent Response Language

// System prompt instructs AI to match user's language
**Language Support:**
- You MUST support both English and Myanmar (Burmese) language
- Detect the user's language from their message
- Respond in the SAME language the user uses
- If user writes in Myanmar, respond in Myanmar
- If user writes in English, respond in English

Key Learning: GPT-4o handles Myanmar language well, but you need explicit instructions in the system prompt to maintain language consistency.

📊 Real-World Usage Examples

Example 1: Daily Sales Check

User: "What were my sales today?"

AI Flow:
1. Intent: sales_query
2. Time range: today (2025-12-06 00:00 to 23:59)
3. Fetch: POS Core → 47 orders
4. Calculate: Total MMK 1,892,400
5. Response: "Your sales today are MMK 1,892,400 from 47 orders. 
   Your average order value is MMK 40,263. 
   Top products: Fried Rice (12 orders), Chicken Curry (8 orders)"

Example 2: Store Operations (Myanmar Language)

User: "စတိုးမှာ ဘယ်နှစ်ခု pending လဲ?"
(Translation: "How many pending orders in the store?")

AI Flow:
1. Intent: store_orders_query
2. Language: Myanmar detected
3. Fetch: Restaurant Service → order stats
4. Response: "သင့်စတိုးမှာ pending အော်ဒါ ၁၅ ခုရှိပါတယ်။ 
   approved ၈ ခု၊ ready ၅ ခုရှိပါတယ်။"
   (Translation: "Your store has 15 pending orders. 
   8 approved, 5 ready.")

Example 3: Inventory Alert

User: "Any low stock items?"

AI Flow:
1. Intent: inventory_query
2. Fetch: Inventory Service → stock levels
3. Analyze: Items with quantity < reorder point
4. Response: "You have 3 items running low:
   - Rice (5kg remaining, reorder at 10kg)
   - Cooking Oil (2L remaining, reorder at 5L)
   - Sugar (3kg remaining, reorder at 5kg)
   Consider restocking soon to avoid shortages."

🎯 Lessons Learned & Best Practices

1. Design for Failure

Microservices fail. Handle it gracefully:

try {
  const response = await axios.get(serviceUrl, { headers, timeout: 5000 });
  return response.data;
} catch (error) {
  console.error(`Service ${serviceUrl} failed:`, error.message);
  
  // Return graceful degradation
  return {
    available: false,
    message: 'Service temporarily unavailable',
    fallback: true
  };
}

2. Start Simple, Optimize Later

I initially tried to build a complex query optimization layer. Wrong move. Start with:

• Direct service calls

• In-memory aggregation

• Simple caching

Only optimize when you have real performance data.

3. Tenant Context Everywhere

Never, ever pass tenant ID as a request parameter. Always:

• Extract from JWT token (source of truth)

• Inject into headers for service calls

• Use as prefix in cache keys

• Validate on every operation

4. Keep AI Context Lean

More context ≠ better responses. I found the sweet spot:

• Last 10 messages for chat history

• Only fetch data relevant to detected intent

• Limit top products to 5 items

• Summarize large datasets before sending to AI

5. Graceful Error Messages

Users don't care about HTTP 503 errors. Transform errors:

// Bad
throw new Error('Failed to fetch from POS Core Service');

// Good
throw new AppError(
  'Unable to retrieve sales data at the moment. Please try again.',
  503
);

🔧 Local Development Setup

Want to build something similar? Here's how to get started:

# 1. Clone and navigate
cd services/chatbot-service

# 2. Install dependencies
npm install

# 3. Configure environment
cp .env.example .env

# Edit .env with your settings:
# PORT=4006
# GITHUB_TOKEN=your-github-token
# REDIS_URL=redis://localhost:6379
# JWT_SECRET=your-secret
# POS_CORE_SERVICE_URL=http://localhost:4002
# INVENTORY_SERVICE_URL=http://localhost:4003
# RESTAURANT_SERVICE_URL=http://localhost:4005

# 4. Start Redis
docker run -d -p 6379:6379 redis:7-alpine

# 5. Run development server
npm run dev

# 6. Test health check
curl http://localhost:4006/health

🚀 Deployment Considerations

Docker Deployment

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY dist ./dist
EXPOSE 4006
CMD ["node", "dist/server.js"]

Environment Variables Checklist

• ✅ GITHUB_TOKEN - AI API authentication

• ✅ JWT_SECRET - Token validation

• ✅ REDIS_URL - Session storage

• ✅ POS_CORE_SERVICE_URL - Sales data source

• ✅ INVENTORY_SERVICE_URL - Stock data source

• ✅ RESTAURANT_SERVICE_URL - Store operations source

• ✅ CORS_ORIGIN - Frontend URL whitelist

Monitoring & Observability

Key metrics to track:

• AI API latency and token usage

• Service integration response times

• Session creation/expiration rates

• Rate limit hit rates per tenant

• Cache hit/miss ratios

• Error rates by service

💭 Reflections: Why This Matters

Building this chatbot taught me that integration is the hardest part of microservices.

It's not about the individual services — those are straightforward. It's about:

• Orchestration: Deciding which services to call when

• Context propagation: Ensuring tenant isolation across 6 different services

• Error handling: Graceful degradation when services fail

• Performance: Balancing data freshness with latency

• User experience: Hiding complexity behind natural language

The AI layer is the easy part. OpenAI, Anthropic, GitHub Models — they all have great APIs. The challenge is building the integration layer that makes it feel magical.

The Bigger Picture

This pattern applies beyond POS systems. Imagine:

• 🏥 Healthcare: "Show me patients with pending lab results"

• 🏦 Banking: "What's my spending trend this month?"

• 📦 Logistics: "Where's my shipment and when will it arrive?"

• 🛒 E-commerce: "Which products are trending in the last week?"

Any domain with multiple microservices and complex queries can benefit from this pattern.

🔗 Architecture Summary

Key Patterns Used:

• ✅ JWT-based authentication with tenant extraction

• ✅ Intent-driven data fetching (only query needed services)

• ✅ Redis-based session management with TTL

• ✅ Service-to-service communication with headers

• ✅ Context injection for AI responses

• ✅ Graceful error handling and fallbacks

• ✅ Rate limiting by tenant ID

• ✅ Bilingual support through prompt engineering

Services Integrated:

• Auth Service (Port 4001) - User authentication

• POS Core (Port 4002) - Orders and sales

• Inventory Service (Port 4003) - Stock management

• Payment Service (Port 4004) - Transaction processing

• Restaurant Service (Port 4005) - Store operations

• Chatbot Service (Port 4006) - AI orchestration

Tech Stack:

• Node.js 18 + TypeScript

• Express.js (REST API)

• Redis (Session storage)

• GitHub Models API (GPT-4o)

• JWT (Authentication)

• Axios (HTTP client)

💬 Final Thoughts

Building an AI-powered chatbot for a microservices architecture is challenging but incredibly rewarding. The key insights:

1. Start with integration, not AI - Get your service communication working first

2. Tenant isolation is non-negotiable - Build it in from day one

3. Keep AI context lean - More data ≠ better responses

4. Design for failure - Services will fail; handle it gracefully

5. Let AI do the heavy lifting - GPT-4o is surprisingly good at intent detection

The future of software interfaces isn't more dashboards — it's natural language conversations backed by intelligent orchestration.

What will you build with this pattern? 🚀

Thanks for reading! If this helped you, consider sharing it with your team. The more developers explore these patterns, the better we all get at building integrated systems.

— Happy coding! 🎉