From Idea to Production

بِسْمِ اللهِ الرَّحْمٰنِ الرَّحِيْمِ

Ahmed noticed something. Small businesses spend hours every day answering the same customer questions—order status, business hours, product availability. One person, typing the same answers over and over.

"What if I could automate this?" he thought. "What if I could build a platform where any business could have an AI chatbot handling their customer inquiries?"

The vision was clear:

• Multi-tenant - One platform, many businesses
• AI-powered - Chatbots that actually understand questions
• Multi-channel - Website widget, mobile app, messaging platforms

Ahmed's first architecture was beautifully simple:

Total cost: $20/month. Total complexity: One docker-compose.yml file.

version: '3.8'
services:
  backend:
    build: ./backend
    ports: ["6000:6000"]
    depends_on: [postgres, redis]

  frontend:
    build: ./frontend
    ports: ["3000:3000"]

  postgres:
    image: postgres:15
    volumes: [postgres_data:/var/lib/postgresql/data]

  redis:
    image: redis:7-alpine

Alternatives Ahmed Considered

The MVP worked. 10 businesses signed up. Ahmed was charging $50/month each. Revenue: $500/month. Profit after server costs: $480.

Life was good. For about 6 weeks.

Month 2. Ahmed wakes up to 47 support messages. All variations of the same thing:

"The app is down."

Ahmed fixed it. Added log rotation. Set up daily backups to S3. Felt smart.

Two weeks later:

The pattern was clear. Every month brought a new "surprise":

The Failure Taxonomy

These failures aren't random. They follow predictable patterns. Name them so you can spot them before they hit you:

Ahmed had 30 paying customers now. $1,500/month revenue. Enough to justify real infrastructure. But which cloud?

The Options

Ahmed chose AWS because:

• Most tutorials and Stack Overflow answers
• ECS for containers (simpler than Kubernetes)
• RDS for managed database (no more disk space surprises)
• His potential enterprise customers already used AWS

The Transformation

Here's what changed when Ahmed moved from a $20 VPS to AWS:

Before diving into infrastructure, let's understand what Ahmed's platform actually does:

Why Separate Services?

How Services Talk to Each Other

Not all services talk to all services. Here's the actual communication map:

Who Calls Who

Ahmed's apps run in Docker containers. But where do those containers run?

The Options

Ahmed chose ECS Fargate because:

• No servers to manage - Fargate handles the underlying infrastructure
• Simpler than Kubernetes - One less thing to learn and debug
• Good enough for 5 services - EKS would be overkill
• Scales automatically - Add tasks when load increases

Key Concepts

Task Definition Anatomy

{
  "family": "backend",
  "cpu": "512",           // 0.5 vCPU
  "memory": "1024",       // 1 GB RAM
  "containerDefinitions": [{
    "name": "api",
    "image": "123456.dkr.ecr.eu-west-1.amazonaws.com/backend:latest",
    "portMappings": [{ "containerPort": 6000 }],
    "healthCheck": {
      "command": ["CMD-SHELL", "wget -q --spider http://127.0.0.1:6000/health"]
    },
    "environment": [
      { "name": "NODE_ENV", "value": "production" }
    ],
    "secrets": [
      { "name": "DATABASE_URL", "valueFrom": "arn:aws:secretsmanager:..." }
    ]
  }]
}

Multi-Stage Builds

Ahmed's Docker images use multi-stage builds to keep them small and secure:

# Stage 1: Build (includes dev dependencies, source code)
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: Run (only what's needed)
FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/server.js"]

ECR: Where Images Live

ECR (Elastic Container Registry) is AWS's Docker image storage. The flow:

Remember Ahmed's disk space disaster with the MVP? That's why he uses RDS now—AWS manages backups, patches, and disk space.

The Options

High Availability

Ahmed uses:

• Multi-AZ for production - Can't afford downtime for customer orders
• Single-AZ for dev - Acceptable risk, saves money

Ahmed has 30 businesses on his platform. Each thinks they have their own system. But they all share the same database. How does this work?

The Options

Ahmed uses Shared DB + tenant_id:

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  tenant_id UUID NOT NULL,  -- The isolation key
  customer_id INT,
  total DECIMAL,
  created_at TIMESTAMP
);

-- Every query filters by tenant
SELECT * FROM orders WHERE tenant_id = $1;

-- Enable RLS on the orders table
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

-- Create a policy: users can only see rows where
-- tenant_id matches the current session variable
CREATE POLICY tenant_isolation ON orders
  USING (tenant_id = current_setting('app.current_tenant')::uuid);

-- In your middleware (runs before every query):
-- SET app.current_tenant = 'tenant-abc';

-- Now this query automatically filters by tenant:
SELECT * FROM orders;
-- ↑ Only returns orders for tenant-abc, even without WHERE clause

async function tenantMiddleware(req, res, next) {
  const tenantId = req.user?.tenantId;
  if (!tenantId) return res.status(401).json({ error: 'No tenant' });

  // IMPORTANT: Validate tenantId format to prevent SQL injection!
  if (!/^[a-f0-9-]{36}$/.test(tenantId)) {
    return res.status(400).json({ error: 'Invalid tenant ID' });
  }

  // Set the tenant for this database connection
  await db.query(`SET app.current_tenant = '${tenantId}'`);
  next();
}

// Now every database query in this request is automatically
// scoped to the authenticated user's tenant. No WHERE clause needed.

Ahmed uses Redis (actually AWS ElastiCache with Valkey) for four different purposes:

Priority Queues

Not all jobs are equal. A payment webhook is more urgent than an analytics update:

Dead Letter Queue

What happens when a job fails after all retries?

Ahmed's traffic varies. Quiet at night, busy during business hours. Why pay for 10 servers at 3 AM when 1 is enough?

Ahmed's Autoscaling Rules

Why Asymmetric Cooldowns?

A request from a user's browser goes through multiple layers. Let's trace a real request: "User clicks 'Ask AI' to get product recommendations."

ALB Routing Rules

One load balancer routes to multiple services based on path:

# Path-based routing
/admin/*        → chatbot-admin:8001
/socket.io/*    → backend:6000      # WebSocket
/api/*          → backend:6000

# Host-based routing
api.example.com → chatbot-api:8000

# Default
/*              → frontend:5000

VPC: Your Private Network

Ahmed's infrastructure lives in a Virtual Private Cloud (VPC)—an isolated network in AWS:

• Public subnets: ALB lives here (accessible from internet)
• Private subnets: Databases, Redis (not accessible from internet)
• Security groups: Firewall rules per service

Back to that phone call at 3:12 AM.

What Changed After

WAF & Rate Limiting

After the incident, Ahmed added two more protection layers:

Ahmed's MVP had no monitoring. He found out about outages from angry customers. Now he has the three pillars:

AWS X-Ray: Distributed Tracing

When a request touches 5 services, which one is slow? AWS X-Ray traces the entire journey:

Request ID: abc-123-def
│
├── Frontend (50ms)
│
├── Backend (350ms)
│   ├── Auth middleware (15ms)
│   ├── Database query (120ms)
│   └── Redis cache check (5ms)
│
└── Chatbot API (1200ms) ← The slow one!
    ├── Weaviate search (400ms)
    └── LLM API call (800ms)

X-Ray answers: "The chatbot's LLM call takes 800ms. Can we cache frequent questions?"

Structured Logging

Ahmed's MVP logs were useless:

// Impossible to search or aggregate
console.log("Order created")
console.log("User logged in")
console.log("Something went wrong")

Now every log is JSON with context:

logger.info({
  event: "order.created",
  orderId: "ord-789",
  tenantId: "tenant-abc",
  userId: "user-456",
  amount: 299.99,
  duration: 145,
  correlationId: req.headers['x-correlation-id']
})

Correlation IDs: Connecting the Dots

A single user action might hit 5 services. How do you find all related logs?

Critical Alarms

Ahmed's deployment is a shell script. Not ideal, but it works:

What's Missing

name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test
      - run: npm audit --audit-level=high

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: eu-west-1

      - name: Login to ECR
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build and push Docker image
        run: |
          docker build -t $ECR_REPO:${{ github.sha }} .
          docker push $ECR_REPO:${{ github.sha }}

      - name: Deploy to ECS
        run: |
          # Update task definition with new image
          aws ecs update-service \
            --cluster production \
            --service api \
            --force-new-deployment

      - name: Wait for stability
        run: |
          aws ecs wait services-stable \
            --cluster production \
            --services api
          # If this times out, ECS auto-rolls back

Ahmed's monthly AWS bill: ~$500

Optimizations Applied

• Right-sized instances: t4g.small instead of m5.large (ARM is cheaper)
• Weekend shutdown: Script stops non-essential services Fri night, starts Mon morning
• Reserved instances: Considering for database (30-70% savings)

Where To Go Deep

Ahmed's journey touched every reliability pattern. Here's where to learn each one in depth:

Continue Learning