DEV Community: Lacey Glenn

Handling Inventory Sync Across Multiple Stores Without Overselling

Lacey Glenn — Tue, 29 Sep 2026 10:02:28 +0000

Selling the same last item to two customers is one of the most frustrating bugs in retail software. It looks small on paper, but it produces cancelled orders, angry customers, and staff who stop trusting the system. If you work on POS software development for multi-store businesses, inventory sync is one of the problems you'll spend the most time on.

This article covers why overselling happens, the main strategies to prevent it, and the trade-offs you'll face along the way. Code examples use PostgreSQL and Node.js-style pseudocode, but the ideas apply to any stack.

Why Overselling Happens

A single store with one terminal is easy: read stock, subtract, save. Problems begin when several things touch the same number at once:

Two cashiers in different stores sell the last unit at the same moment.
An online order and an in-store sale hit the same SKU together.
A terminal goes offline, keeps selling from stale data, and syncs later.
A network retry submits the same sale twice.

The classic culprit is the read-modify-write race condition:

Store A reads stock: 1
Store B reads stock: 1
Store A sells 1 and writes: 0
Store B sells 1 and writes: 0   // both sales succeeded, only 1 unit existed

Both writes look valid in isolation. The bug only exists in the interleaving.

Rule 1: Never Store Stock as a Single Overwritten Number

If your schema has just products.quantity and every sale does UPDATE ... SET quantity = <value your app computed>, you will lose updates.

At minimum, make the database do the math atomically:

UPDATE inventory
SET quantity = quantity - 1
WHERE product_id = $1
  AND store_id = $2
  AND quantity >= 1;

If this affects zero rows, the sale must be rejected or handled as backorder. The condition quantity >= 1 and the decrement happen in one atomic statement, so two concurrent sales can't both succeed on the last unit.

Rule 2: Use an Append-Only Ledger

A more robust design records every stock change as an immutable event, and treats the quantity as something derived from those events.

CREATE TABLE inventory_movements (
  id           BIGSERIAL PRIMARY KEY,
  store_id     INT NOT NULL,
  product_id   INT NOT NULL,
  delta        INT NOT NULL,          -- +10 received, -1 sold, -2 damaged
  reason       TEXT NOT NULL,         -- sale, return, transfer, adjustment
  reference_id TEXT NOT NULL,         -- order ID, transfer ID, etc.
  created_at   TIMESTAMPTZ DEFAULT now(),
  UNIQUE (reference_id, product_id, store_id, reason)
);

Benefits:

Full audit trail. You can answer "why is this number wrong?"
Safer syncing. Terminals send events, not overwritten totals, so nothing gets clobbered.
Idempotency. The unique constraint stops the same sale from being counted twice.

For speed, keep a cached balance table updated in the same transaction as the ledger insert, and periodically reconcile it against the sum of movements.

Rule 3: Make Every Write Idempotent

Networks fail. A terminal sends a sale, the server processes it, the response is lost, and the terminal retries. Without protection, stock is deducted twice.

Attach a unique idempotency key (for example, a UUID generated on the terminal when the sale starts) to every request:

async function recordSale(sale) {
  return db.tx(async (t) => {
    const inserted = await t.result(
      `INSERT INTO processed_requests (key) VALUES ($1)
       ON CONFLICT DO NOTHING`,
      [sale.idempotencyKey]
    );

    if (inserted.rowCount === 0) {
      return { status: 'already_processed' };
    }

    for (const line of sale.items) {
      const res = await t.result(
        `UPDATE inventory
         SET quantity = quantity - $1
         WHERE product_id = $2 AND store_id = $3 AND quantity >= $1`,
        [line.qty, line.productId, sale.storeId]
      );
      if (res.rowCount === 0) throw new Error('INSUFFICIENT_STOCK');
    }

    return { status: 'ok' };
  });
}

If the retry arrives, the second insert does nothing and the sale isn't applied again.

Strategy 1: Central Source of Truth (Strong Consistency)

All stores talk to one central database, and every sale checks and decrements stock there.

Pros: Simple to reason about, no overselling if done atomically.
Cons: Every sale depends on connectivity and latency. If the connection drops, the store can't sell, which is unacceptable for many retailers.

This is a good starting point for small chains with reliable internet.

Strategy 2: Reservations for Online and Cross-Store Orders

For online orders, click-and-collect, and inter-store transfers, don't decrement stock immediately. Create a reservation with an expiry.

CREATE TABLE reservations (
  id          UUID PRIMARY KEY,
  product_id  INT NOT NULL,
  store_id    INT NOT NULL,
  quantity    INT NOT NULL,
  expires_at  TIMESTAMPTZ NOT NULL,
  status      TEXT NOT NULL  -- active, confirmed, released, expired
);

Available-to-sell becomes:

available = on_hand - active_reservations

When payment is confirmed, convert the reservation to a sale. If checkout is abandoned, a background job releases expired reservations. This prevents two shoppers from buying the same unit while one is still paying.

Strategy 3: Offline-First Terminals With Safety Buffers

Many stores can't afford to stop selling when the internet drops. In that case, each terminal keeps a local database (SQLite is common), sells against local stock, and syncs later.

The catch is that local stock can be stale, so you need a policy for the risk:

Safety stock buffer. Show online channels only a portion of stock, such as on-hand minus 2 units, so offline stores have headroom.
Store-owned stock. Each store sells only its own inventory, so two stores can never conflict over the same physical unit. Cross-store availability is shown as "available at another store" and requires a transfer.
Allocation for hot items. For high-demand SKUs, allocate stock per channel or per store rather than sharing one pool.
Accept and reconcile. For low-value items, allow small oversells and resolve them through the ledger, with a defined process (substitute, refund, or transfer).

The right choice depends on your business. A grocery chain can tolerate small discrepancies. A store selling limited-edition items or high-value electronics cannot.

Strategy 4: Event-Driven Sync Between Stores

For larger systems, stores publish inventory events to a message broker (Kafka, RabbitMQ, or a managed queue), and a central service processes them in order.

Key points:

Ordering matters per SKU. Partition messages by product ID so events for one item are processed sequentially.
Consumers must be idempotent. Messages can be delivered more than once.
Handle failures. Use retries with backoff and a dead-letter queue for events that can't be processed.
Expect eventual consistency. Other stores' views will lag by seconds, so design the UI to reflect that ("Last updated 20 seconds ago").

Locking: Pessimistic vs. Optimistic

When you need to check-and-update multiple rows (for example, a bundle with several components), you may need explicit concurrency control.

Pessimistic locking locks the rows while you work:

BEGIN;
SELECT quantity FROM inventory
WHERE product_id = $1 AND store_id = $2
FOR UPDATE;
-- check and update
COMMIT;

Safe, but it can create contention on popular items.

Optimistic locking uses a version number and retries on conflict:

UPDATE inventory
SET quantity = quantity - 1, version = version + 1
WHERE product_id = $1 AND store_id = $2 AND version = $3;

Better for low-conflict workloads, but you need retry logic.

For most POS workloads, the single atomic UPDATE ... WHERE quantity >= n statement is the simplest and fastest option. Reach for explicit locks only when a business rule spans multiple rows.

Reconciliation: Assume Drift Will Happen

Even with good design, real-world stock drifts because of theft, damage, miscounts, and human error. Build reconciliation into the product:

Scheduled cycle counts that create adjustment movements in the ledger.
Alerts when calculated stock goes negative or diverges from counts.
A report of oversell incidents and their causes, so you can see which strategy is failing.
Clear audit trails showing who changed what, and when.

Software can prevent digital errors. It can't fully prevent physical ones, so reconciliation is part of the design, not an afterthought.

Testing Concurrency Bugs

Race conditions rarely show up in normal testing. Test them deliberately:

Fire hundreds of simultaneous requests at a SKU with stock of 1 and assert exactly one succeeds.
Replay the same request multiple times to verify idempotency.
Simulate a terminal going offline, selling, and reconnecting.
Kill the server mid-transaction and confirm no partial deductions.
Run load tests that mimic sale-day traffic.

A simple test:

const results = await Promise.allSettled(
  Array.from({ length: 50 }, () => recordSale(makeSale({ qty: 1 })))
);
const successes = results.filter(r => r.status === 'fulfilled' && r.value.status === 'ok');
assert.equal(successes.length, 1);

Choosing a Strategy: A Quick Guide

Situation	Recommended approach
Few stores, reliable internet	Central database with atomic updates
Online and click-and-collect orders	Reservations with expiry
Unreliable connectivity	Offline-first terminals plus safety buffers
Many stores, high volume	Event-driven sync with per-SKU ordering
Limited or high-value stock	Strong consistency, no offline overselling

Key Takeaways

Never overwrite stock with an app-computed value. Let the database do atomic, conditional updates.
Prefer an append-only ledger of movements over a single mutable number.
Make every write idempotent, because retries are guaranteed.
Decide explicitly how much overselling risk your business can tolerate, then pick consistency or availability accordingly.
Reconcile regularly, and test concurrency on purpose.

Good POS software development isn't about eliminating every edge case. It's about choosing the trade-offs that fit the retailer, making failures visible, and giving staff a clear way to fix them.

Before publishing on dev.to:

Add a personal angle, such as a real oversell bug you hit or a store scenario you've worked on. Original experience helps indexing and reader trust.
Suggested tags: #postgres, #architecture, #webdev, #database.
Add a simple diagram of the race condition and the ledger flow, and consider making this part of a series (for example, "Building a POS: Part 3").
Test the code snippets in your own environment before publishing, since they're simplified illustrations rather than production-ready code.

Build an AI Trip Planner With an LLM API and Structured JSON Output

Lacey Glenn — Mon, 28 Sep 2026 12:02:52 +0000

---
title: "Build an AI Trip Planner With an LLM API and Structured JSON Output"
published: false
description: "Turn a free-form travel request into a validated, typed itinerary your app can render, using tool calling, a JSON schema and a retry loop."
tags: ai, typescript, node, tutorial
series: Building a Travel App From Scratch
---

Build an AI Trip Planner With an LLM API and Structured JSON Output

Ask an LLM for a three-day Lisbon itinerary and you get a lovely paragraph. Ask your app to display that paragraph as a card per day, with times and costs, and you have a problem. Free text is for humans. Apps need data.

In this post we'll build a small trip planner backend that returns a validated, typed itinerary every time. We'll cover:

Forcing the model to return JSON that matches a schema
Validating the result with Zod
Checking business rules the schema can't express (budget, day count)
Retrying with feedback when the output is wrong
Exposing it through an Express endpoint

Stack: Node 20+, TypeScript, Express, Zod and the Anthropic SDK. The ideas work with any provider that supports tool calling or a JSON schema mode.

Why not just say "respond in JSON"?

You can ask nicely in the prompt, and it will often work. In production, "often" means a broken screen for some users: markdown fences around the JSON, a missing field, a string where you expected a number, or a cheerful sentence before the opening brace.

There are two more reliable approaches:

Tool calling with a forced tool. You describe a function with a JSON schema, and tell the model it must call it. The arguments arrive as structured data instead of prose.
Native JSON schema output modes, where the provider supports them.

We'll use forced tool calling, then validate anyway. A schema constrains the model, but your own validation is what protects your app.

Project setup

mkdir ai-trip-planner && cd ai-trip-planner
npm init -y
npm i express zod @anthropic-ai/sdk
npm i -D typescript tsx @types/node @types/express
npx tsc --init
export ANTHROPIC_API_KEY="your-key-here"

Never commit your key. Use environment variables or a secrets manager.

Step 1: Define the shape of a trip

Start with the output you want, not the prompt. Here's the Zod schema:

// src/schema.ts
import { z } from "zod";

export const ActivitySchema = z.object({
  time: z.string().regex(/^\d{2}:\d{2}$/, "Use 24h HH:MM"),
  title: z.string().min(1),
  description: z.string().min(1),
  category: z.enum(["food", "sightseeing", "culture", "outdoors", "transport", "rest"]),
  estimatedCostUsd: z.number().min(0),
});

export const DaySchema = z.object({
  day: z.number().int().min(1),
  theme: z.string().min(1),
  activities: z.array(ActivitySchema).min(1),
});

export const ItinerarySchema = z.object({
  destination: z.string().min(1),
  days: z.array(DaySchema).min(1),
  packingTips: z.array(z.string()).max(6),
});

export type Itinerary = z.infer<typeof ItinerarySchema>;

export const TripRequestSchema = z.object({
  destination: z.string().min(2).max(80),
  days: z.number().int().min(1).max(14),
  budgetUsd: z.number().positive(),
  interests: z.array(z.string().max(40)).max(5).default([]),
});

export type TripRequest = z.infer<typeof TripRequestSchema>;

Notice what's missing: a totalCost field. Don't make an LLM do arithmetic you can do in code. Models are decent at it but not reliable, so we'll compute totals ourselves later. Every field you remove is one less thing that can be wrong.

Step 2: Describe the same shape as a tool

The model needs the schema in JSON Schema form. You can generate it from Zod with a helper library, or write it by hand as here:

// src/tool.ts
import type Anthropic from "@anthropic-ai/sdk";

export const itineraryTool: Anthropic.Tool = {
  name: "create_itinerary",
  description: "Return a complete day-by-day travel itinerary for the requested trip.",
  input_schema: {
    type: "object",
    properties: {
      destination: { type: "string" },
      days: {
        type: "array",
        items: {
          type: "object",
          properties: {
            day: { type: "integer", minimum: 1 },
            theme: { type: "string" },
            activities: {
              type: "array",
              items: {
                type: "object",
                properties: {
                  time: { type: "string", description: "24h time, HH:MM" },
                  title: { type: "string" },
                  description: { type: "string" },
                  category: {
                    type: "string",
                    enum: ["food", "sightseeing", "culture", "outdoors", "transport", "rest"],
                  },
                  estimatedCostUsd: { type: "number", minimum: 0 },
                },
                required: ["time", "title", "description", "category", "estimatedCostUsd"],
              },
            },
          },
          required: ["day", "theme", "activities"],
        },
      },
      packingTips: { type: "array", items: { type: "string" } },
    },
    required: ["destination", "days", "packingTips"],
  },
};

Step 3: Call the model and force the tool

// src/planner.ts
import Anthropic from "@anthropic-ai/sdk";
import { ItinerarySchema, type Itinerary, type TripRequest } from "./schema";
import { itineraryTool } from "./tool";

const client = new Anthropic(); // reads ANTHROPIC_API_KEY
const MODEL = process.env.LLM_MODEL ?? "claude-sonnet-5"; // check current model names in the docs

const SYSTEM = `You are a careful travel planner.
- Plan realistic days: group nearby places, leave time to travel and rest.
- Use estimated costs in USD per person for each activity.
- Only suggest well-known, real places. If unsure a place exists, choose something else.
- Never include booking links or claim live availability or prices.`;

function buildPrompt(req: TripRequest, feedback?: string[]) {
  let prompt =
    `Plan a ${req.days}-day trip to ${req.destination}.\n` +
    `Total activity budget per person: $${req.budgetUsd} USD.\n` +
    `Interests: ${req.interests.join(", ") || "general sightseeing"}.\n` +
    `Return exactly ${req.days} days.`;
  if (feedback?.length) {
    prompt += `\n\nYour previous attempt had problems. Fix all of them:\n- ${feedback.join("\n- ")}`;
  }
  return prompt;
}

Step 4: Validate schema and business rules

A schema can say "this is a number." It can't say "the days must match what the user asked for" or "stay under budget." Those need code:

function totalCost(it: Itinerary) {
  return it.days
    .flatMap((d) => d.activities)
    .reduce((sum, a) => sum + a.estimatedCostUsd, 0);
}

function checkBusinessRules(it: Itinerary, req: TripRequest): string[] {
  const problems: string[] = [];

  if (it.days.length !== req.days) {
    problems.push(`Expected ${req.days} days but got ${it.days.length}.`);
  }

  const total = totalCost(it);
  if (total > req.budgetUsd) {
    problems.push(`Activities cost $${total} in total, above the $${req.budgetUsd} budget.`);
  }

  it.days.forEach((d, i) => {
    if (d.day !== i + 1) problems.push(`Day numbering is wrong at position ${i + 1}.`);
    const times = d.activities.map((a) => a.time);
    if ([...times].sort().join() !== times.join()) {
      problems.push(`Day ${d.day} activities are not in chronological order.`);
    }
  });

  return problems;
}

Step 5: The retry loop with feedback

This is the part that makes the system dependable. When validation fails, we don't just retry blindly. We tell the model what was wrong:

export async function planTrip(req: TripRequest, maxAttempts = 3) {
  let feedback: string[] | undefined;

  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    const response = await client.messages.create({
      model: MODEL,
      max_tokens: 4000,
      system: SYSTEM,
      tools: [itineraryTool],
      tool_choice: { type: "tool", name: itineraryTool.name },
      messages: [{ role: "user", content: buildPrompt(req, feedback) }],
    });

    const call = response.content.find(
      (b): b is Anthropic.ToolUseBlock => b.type === "tool_use"
    );
    if (!call) {
      feedback = ["No structured itinerary was returned."];
      continue;
    }

    const parsed = ItinerarySchema.safeParse(call.input);
    if (!parsed.success) {
      feedback = parsed.error.issues.map((i) => `${i.path.join(".")}: ${i.message}`);
      continue;
    }

    const problems = checkBusinessRules(parsed.data, req);
    if (problems.length === 0) {
      return { itinerary: parsed.data, totalCostUsd: totalCost(parsed.data), attempts: attempt };
    }
    feedback = problems;
  }

  throw new Error("Could not produce a valid itinerary");
}

Two design choices worth noting:

Feedback is specific. "Day 2 activities are not in chronological order" fixes problems far more often than "try again."
Attempts are capped. An unbounded loop is an unbounded bill. Three is a sensible default, and you should log how often attempt two or three is needed. That number tells you whether your prompt or schema needs work.

Step 6: Wrap it in an API

// src/server.ts
import express from "express";
import { TripRequestSchema } from "./schema";
import { planTrip } from "./planner";

const app = express();
app.use(express.json({ limit: "10kb" }));

app.post("/api/plan", async (req, res) => {
  const input = TripRequestSchema.safeParse(req.body);
  if (!input.success) {
    return res.status(400).json({ error: input.error.flatten() });
  }

  try {
    const result = await planTrip(input.data);
    res.json(result);
  } catch (err) {
    console.error(err);
    res.status(502).json({ error: "Could not generate a valid itinerary. Please try again." });
  }
});

app.listen(3000, () => console.log("Trip planner on http://localhost:3000"));

Run it and test:

npx tsx src/server.ts

curl -X POST http://localhost:3000/api/plan \
  -H "Content-Type: application/json" \
  -d '{"destination":"Lisbon","days":3,"budgetUsd":250,"interests":["food","history"]}'

You'll get back typed JSON your frontend can map straight to UI: one card per day, a timeline per card, and a computed total.

Things that will bite you in production

The model can hallucinate places and prices. Structured output guarantees the shape, not the truth. Treat costs as estimates and label them that way. For real accuracy, ground the model in data: call a places API and pass verified results in, or verify each suggested venue afterwards.

Untrusted input goes into your prompt. Users control destination and interests. Keep length limits (as in the schema above), and never give the model tools that can take actions on the user's behalf without checks.

Rate limits and cost. Cache identical requests, set max_tokens deliberately, and add per-user rate limits before you expose this publicly.

Latency. Generating a long itinerary takes seconds. Consider streaming progress to the UI, or generating one day at a time so the first day appears quickly.

Test with an eval set. Keep 20 to 30 requests, including weird ones ("1 day in Antarctica on a $10 budget"), and run them after every prompt change. Track the validation-pass rate and the average number of attempts.

Where to go next

Add a regenerate day endpoint that changes one day while keeping the others fixed
Ground activities with a real places or maps API
Store itineraries in a database and let users edit them
Add streaming so the UI fills in as the plan is generated
Turn the schema into a shared package used by both backend and frontend

Wrapping up

The key idea is simple: treat the LLM as an untrusted data source, not as your app's logic. Constrain its output with a schema, validate it like any external input, enforce your own rules in code, and give it precise feedback when it gets things wrong. Do that, and "AI trip planner" stops being a demo and starts being a feature you can ship.

If you build on this, I'd love to hear what breaks first in your tests. Drop it in the comments.

How to Build a Feed Ranking Algorithm From Scratch (Simplified)

Lacey Glenn — Fri, 25 Sep 2026 12:35:10 +0000

If you've ever built a social app, you've hit this problem: you have posts, you have users, and you need to decide what shows up first. Sorting by created_at DESC works for exactly one afternoon. After that, your most recent post buries something way more relevant from three hours ago, and your users start wondering why the app feels dead.

This post walks through building a real, working feed ranking algorithm from scratch — not a black-box ML model, just the actual logic (with code) behind how platforms like early Facebook, early Twitter, and most consumer feeds decide what goes where. We'll keep it simplified, but every piece here is a real technique used in production systems, just without the years of A/B-tested tuning layered on top.

The Core Idea: Ranking Is Just Scoring + Sorting

Strip away the mystique and a feed ranking algorithm is two steps:

Score every candidate post for a given user
Sort by that score, descending

That's it. The entire game is in how you calculate the score. So let's build a scoring function piece by piece.

Step 1: Start With a Naive Baseline

Before adding intelligence, let's establish what we're improving on:

def naive_score(post):
    return post["created_at"].timestamp()

feed = sorted(posts, key=naive_score, reverse=True)

This is recency-only sorting. It's simple, but it has an obvious flaw: a mediocre post from 2 minutes ago beats a genuinely great post from 2 hours ago, every time. We need to factor in quality and relevance, not just freshness.

Step 2: Define Your Ranking Signals

Every real feed ranking system is built on three categories of signals:

Engagement signals — likes, comments, shares, saves (how good is this post, generally?)
Relevance signals — how related is this post to this specific user?
Recency signals — how fresh is it?

Let's build a signal for each.

Engagement Score

def engagement_score(post):
    likes = post.get("likes", 0)
    comments = post.get("comments", 0)
    shares = post.get("shares", 0)

    # Comments and shares are stronger signals than likes —
    # they take more effort, so weight them higher
    return (likes * 1.0) + (comments * 3.0) + (shares * 5.0)

Weighting matters here. A like takes one tap. A comment takes intent. A share means someone found it worth broadcasting to their own network. Most real systems weight these very differently — this is a simplified version of that logic.

Relevance Score

This is where personalization comes in. A basic version compares the post author to the user's past interaction history:

def relevance_score(post, user_history):
    author_id = post["author_id"]

    # How many times has this user engaged with this author before?
    past_engagements = user_history.get(author_id, 0)

    # Diminishing returns — 10 past likes shouldn't count 10x more
    # than 3 past likes, or the feed becomes an echo chamber
    import math
    return math.log1p(past_engagements) * 2.0

Using log1p (log(1 + x)) instead of raw counts prevents a single over-followed account from permanently dominating the user's feed — a real problem if you don't cap this signal.

Recency Score with Decay

Instead of pure timestamp sorting, we apply time decay — a post's relevance score shrinks the older it gets, but doesn't disappear immediately:

import time

def recency_score(post, half_life_hours=6):
    age_hours = (time.time() - post["created_at"].timestamp()) / 3600
    decay = 0.5 ** (age_hours / half_life_hours)
    return decay

A half_life_hours=6 means a post's recency score is cut in half every 6 hours. This is the same math used to model radioactive decay — and it's a genuinely good fit here, because it lets old-but-great content still surface without letting stale content dominate.

Step 3: Combine the Signals

Now we combine everything into a single weighted score:

def rank_score(post, user_history, weights=None):
    weights = weights or {
        "engagement": 0.4,
        "relevance": 0.4,
        "recency": 0.2,
    }

    e_score = engagement_score(post)
    r_score = relevance_score(post, user_history)
    t_score = recency_score(post)

    # Normalize engagement so it doesn't dwarf the other signals
    # (a viral post with 50,000 likes shouldn't break the math)
    import math
    e_score_normalized = math.log1p(e_score)

    final_score = (
        weights["engagement"] * e_score_normalized +
        weights["relevance"] * r_score +
        weights["recency"] * t_score
    )
    return final_score

Notice the weights dict is exposed as a parameter, not hardcoded. This matters a lot in practice — these weights are exactly what platforms tune constantly through A/B testing. Your first guess at 0.4/0.4/0.2 will be wrong. That's fine. The architecture just needs to make it easy to change.

Step 4: Build the Actual Feed

def build_feed(posts, user_history):
    scored = [
        (post, rank_score(post, user_history))
        for post in posts
    ]
    scored.sort(key=lambda x: x[1], reverse=True)
    return [post for post, score in scored]

feed = build_feed(candidate_posts, current_user_history)

At this point, you have a working, personalized, decay-aware feed ranking system. It's simplified, but structurally, it's not far off from what real early-stage social platforms ran in production.

Common Pitfalls (Learned the Hard Way)

1. Forgetting to normalize wildly different scales.
Engagement counts can range from 0 to 100,000+. Relevance and recency scores typically live between 0 and 1. If you don't normalize (notice the log1p calls above), your engagement signal will silently dominate everything else and your "personalized" feed becomes "just show whatever's viral."

2. No diversity control.
A pure score-and-sort approach will happily show a user 8 posts in a row from the same account if that account scores highest. Real systems add a diversity pass after scoring — for example, capping consecutive posts from the same author:

def diversify(ranked_posts, max_consecutive=2):
    result = []
    last_author = None
    consecutive_count = 0

    for post in ranked_posts:
        if post["author_id"] == last_author:
            consecutive_count += 1
        else:
            consecutive_count = 1
            last_author = post["author_id"]

        if consecutive_count <= max_consecutive:
            result.append(post)

    return result

3. Ignoring negative signals.
"Hide post," "unfollow," and fast scroll-past behavior are just as valuable as likes — arguably more valuable, since they're explicit. A more mature version of relevance_score should subtract for these, not just add for positive engagement.

4. Recomputing the entire feed on every request.
This naive implementation re-scores every candidate post per request, which doesn't scale. Production systems typically pre-compute candidate sets (via a "candidate generation" stage using approximate nearest-neighbor search or simple following-graph queries) and only run the expensive ranking pass on a few hundred candidates, not your entire posts table.

Where This Goes Next

This is deliberately the "classical" approach — weighted scoring functions with hand-tuned coefficients. It's exactly how most feed ranking worked before deep learning became cheap enough to run at inference time for every request.

The natural next step, once you have real usage data, is replacing hand-picked weights with a learned model — typically a gradient-boosted tree (like XGBoost) or a small neural network trained on historical engagement data to predict P(user will engage with this post), then ranking by that predicted probability instead of a manual formula.

But here's the thing worth saying plainly: don't start there. The hand-tuned version above will outperform a half-trained ML model for a long time, because ML models need volume and clean labels to beat a well-reasoned heuristic. Ship the simple version, watch how users actually behave, and let the data tell you when it's time to graduate to a learned ranker — not before.

Full Code Recap

import math
import time

def engagement_score(post):
    likes = post.get("likes", 0)
    comments = post.get("comments", 0)
    shares = post.get("shares", 0)
    return (likes * 1.0) + (comments * 3.0) + (shares * 5.0)

def relevance_score(post, user_history):
    past_engagements = user_history.get(post["author_id"], 0)
    return math.log1p(past_engagements) * 2.0

def recency_score(post, half_life_hours=6):
    age_hours = (time.time() - post["created_at"].timestamp()) / 3600
    return 0.5 ** (age_hours / half_life_hours)

def rank_score(post, user_history, weights=None):
    weights = weights or {"engagement": 0.4, "relevance": 0.4, "recency": 0.2}
    e = math.log1p(engagement_score(post))
    r = relevance_score(post, user_history)
    t = recency_score(post)
    return weights["engagement"] * e + weights["relevance"] * r + weights["recency"] * t

def build_feed(posts, user_history):
    scored = [(p, rank_score(p, user_history)) for p in posts]
    scored.sort(key=lambda x: x[1], reverse=True)
    return [p for p, s in scored]

Copy this, plug in your own post data, and you've got a real, working starting point — not a toy example, an actual foundation you can iterate on as you learn what your users respond to.

How to Build an Infinite Scroll Feed with React

Lacey Glenn — Thu, 24 Sep 2026 12:53:40 +0000

Infinite scrolling is commonly used in social media feeds, news websites, marketplaces, and content platforms. Instead of loading every post at once, the application loads a small batch of content and fetches more when the user reaches the bottom of the page.

This approach can improve the initial loading experience and reduce the amount of data requested at once.

In this tutorial, we'll build a simple infinite scroll feed with React using the browser's IntersectionObserver API.

What We'll Build

Our example will:

Display a list of posts
Load posts in batches
Detect when the user reaches the bottom
Fetch the next batch automatically
Show a loading indicator
Stop requesting data when there are no more posts
Handle basic API errors

1. Create a React Application

If you're starting a new project, you can create one with Vite:

npm create vite@latest infinite-scroll-feed -- --template react
cd infinite-scroll-feed
npm install
npm run dev

For this example, we'll keep the application simple and focus on the infinite-scroll logic.

2. Create a Feed Component

Start with a basic component that stores the posts and loading state.

import { useEffect, useRef, useState } from "react";

function Feed() {
  const [posts, setPosts] = useState([]);
  const [page, setPage] = useState(1);
  const [loading, setLoading] = useState(false);
  const [hasMore, setHasMore] = useState(true);

  return (
    <div>
      <h1>Social Feed</h1>

      {posts.map((post) => (
        <article key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.body}</p>
        </article>
      ))}

      {loading && <p>Loading...</p>}
    </div>
  );
}

export default Feed;

The important state variables are:

posts stores the posts already loaded.
page keeps track of which batch should be requested next.
loading prevents multiple requests from running at the same time.
hasMore tells us whether additional posts are available.

3. Fetch Posts from an API

For demonstration, we can use a simple API such as JSONPlaceholder.

Create a function that retrieves a batch of posts:

const fetchPosts = async (pageNumber) => {
  const response = await fetch(
    `https://jsonplaceholder.typicode.com/posts?_page=${pageNumber}&_limit=10`
  );

  if (!response.ok) {
    throw new Error("Failed to fetch posts");
  }

  return response.json();
};

The _page parameter tells the API which page we want, while _limit controls how many posts are returned.

In a production application, your API might look more like:

/api/posts?page=2&limit=20

4. Load the Initial Posts

We can use useEffect to load the first batch when the component mounts.

useEffect(() => {
  const loadPosts = async () => {
    setLoading(true);

    try {
      const newPosts = await fetchPosts(page);

      setPosts((currentPosts) => [
        ...currentPosts,
        ...newPosts
      ]);

      if (newPosts.length === 0) {
        setHasMore(false);
      }
    } catch (error) {
      console.error(error);
    } finally {
      setLoading(false);
    }
  };

  loadPosts();
}, [page]);

Whenever page changes, React runs the effect again and loads the next batch.

However, we still need a way to automatically increase the page number when the user reaches the bottom.

5. Detect the Bottom of the Feed

This is where IntersectionObserver becomes useful.

Create a reference for a small element placed at the bottom of the feed:

const loaderRef = useRef(null);

Then add the observer:

useEffect(() => {
  const observer = new IntersectionObserver(
    (entries) => {
      if (entries[0].isIntersecting && !loading && hasMore) {
        setPage((currentPage) => currentPage + 1);
      }
    },
    {
      threshold: 1.0
    }
  );

  if (loaderRef.current) {
    observer.observe(loaderRef.current);
  }

  return () => observer.disconnect();
}, [loading, hasMore]);

The observer watches the element at the bottom of the feed.

When that element becomes visible, we increase the page number.

6. Add the Loader Element

Place the loader at the end of the posts:

{posts.map((post) => (
  <article key={post.id}>
    <h2>{post.title}</h2>
    <p>{post.body}</p>
  </article>
))}

<div ref={loaderRef}>
  {loading && <p>Loading more posts...</p>}
</div>

When the user approaches the bottom, the loader enters the viewport and triggers another request.

7. Complete Example

Here's the complete component:

import { useEffect, useRef, useState } from "react";

function Feed() {
  const [posts, setPosts] = useState([]);
  const [page, setPage] = useState(1);
  const [loading, setLoading] = useState(false);
  const [hasMore, setHasMore] = useState(true);

  const loaderRef = useRef(null);

  const fetchPosts = async (pageNumber) => {
    const response = await fetch(
      `https://jsonplaceholder.typicode.com/posts?_page=${pageNumber}&_limit=10`
    );

    if (!response.ok) {
      throw new Error("Failed to fetch posts");
    }

    return response.json();
  };

  useEffect(() => {
    const loadPosts = async () => {
      setLoading(true);

      try {
        const newPosts = await fetchPosts(page);

        setPosts((currentPosts) => [
          ...currentPosts,
          ...newPosts
        ]);

        if (newPosts.length === 0) {
          setHasMore(false);
        }
      } catch (error) {
        console.error(error);
      } finally {
        setLoading(false);
      }
    };

    loadPosts();
  }, [page]);

  useEffect(() => {
    const observer = new IntersectionObserver(
      (entries) => {
        if (entries[0].isIntersecting && !loading && hasMore) {
          setPage((currentPage) => currentPage + 1);
        }
      },
      {
        threshold: 1.0
      }
    );

    if (loaderRef.current) {
      observer.observe(loaderRef.current);
    }

    return () => observer.disconnect();
  }, [loading, hasMore]);

  return (
    <main>
      <h1>Social Feed</h1>

      {posts.map((post) => (
        <article key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.body}</p>
        </article>
      ))}

      <div ref={loaderRef}>
        {loading && <p>Loading more posts...</p>}

        {!hasMore && <p>No more posts.</p>}
      </div>
    </main>
  );
}

export default Feed;

Why Use IntersectionObserver?

A common alternative is listening for the browser's scroll event:

window.addEventListener("scroll", handleScroll);

This can work, but scroll events may fire very frequently. You then need to calculate the user's position and determine whether they've reached the bottom.

IntersectionObserver provides a cleaner approach by allowing the browser to notify your application when an element enters or leaves the viewport.

Handling Duplicate Requests

Infinite scrolling can accidentally trigger multiple requests if the user reaches the bottom while a request is still running.

That's why this condition is important:

if (entries[0].isIntersecting && !loading && hasMore)

The !loading check prevents another page request while the current request is still being processed.

For more complex applications, you can also use AbortController to cancel requests when necessary.

Infinite Scroll for a Real Social Media App

A real social media feed usually needs more than a basic page number.

For example, an API might use cursor-based pagination:

GET /api/feed?limit=20&cursor=abc123

The server could return:

{
  "posts": [],
  "nextCursor": "xyz789",
  "hasMore": true
}

Cursor-based pagination is often useful for feeds where new content is continuously being created because it can avoid some of the consistency problems associated with traditional page numbers.

The frontend can then request:

/api/feed?limit=20&cursor=xyz789

to retrieve the next batch.

Performance Considerations

Infinite scrolling doesn't automatically make an application fast.

If thousands of posts remain mounted in the DOM, the page can eventually become expensive to render.

For large feeds, consider:

1. Virtualization

Libraries such as react-window can render only the items currently visible or near the viewport.

2. Image Lazy Loading

Use lazy loading for images:

<img
  src={post.image}
  alt={post.title}
  loading="lazy"
/>

3. Smaller API Responses

Only request the fields needed by the feed.

Instead of returning a large user profile, media metadata, and unrelated information, return the data required to render each feed item.

4. Cursor-Based Pagination

For large and frequently changing feeds, cursor-based pagination can provide more consistent results than simple page numbers.

5. Caching

Caching previously requested data can reduce unnecessary network requests and improve navigation.

Common Problems

Duplicate Posts

This can happen when pagination requests overlap or when the backend changes between requests.

Use stable IDs and carefully manage pagination state.

setPosts((currentPosts) => {
  const existingIds = new Set(currentPosts.map((post) => post.id));

  const uniquePosts = newPosts.filter(
    (post) => !existingIds.has(post.id)
  );

  return [...currentPosts, ...uniquePosts];
});

Endless Requests

Always maintain a clear stopping condition such as:

hasMore

Otherwise, the observer can continue requesting pages indefinitely.

Poor Mobile Performance

Large images, excessive DOM nodes, expensive components, and unnecessary re-renders can make an infinite feed feel slow on mobile devices.

Profile the application before adding optimization blindly.

Conclusion

Building an infinite scroll feed with React doesn't require complicated code. The basic pattern is:

Fetch the first batch of posts.
Render the posts.
Place a sentinel element at the bottom.
Monitor it with IntersectionObserver.
Request the next batch when it becomes visible.
Stop when there is no more content.
Add virtualization, caching, and optimized media handling as the feed grows.

For a small application, page-based pagination may be enough. For a large social platform, you'll typically need additional considerations such as cursor-based pagination, caching, virtualization, efficient APIs, and scalable backend architecture.

Why Users Who DM Each Other Are 4x More Likely to Come Back — And What That Means for Your Architecture

Lacey Glenn — Wed, 23 Sep 2026 13:08:42 +0000

If you're building a social app, there's a retention stat worth internalizing before you write a single line of feed-ranking code: users who DM each other are reportedly about 4x more likely to return daily than users who don't. That number comes from industry analysis of social app engagement patterns, and while any single stat like this deserves some skepticism about methodology, it lines up with what most social products discover the hard way — the feed gets people in the door, but private messaging is what makes them stay.

This has a real architectural implication that a lot of early-stage social apps miss: DMs aren't a nice-to-have bolted onto a content platform. If retention data says messaging drives return visits, then your real-time messaging layer deserves the same architectural seriousness as your feed — not a rushed implementation shipped after the "core" product is done.

Here's what building that layer properly actually involves.

Why DMs are architecturally harder than they look

On paper, direct messaging looks simple: user A sends a message, user B receives it. In practice, a production-grade DM system has to handle:

Real-time delivery to online users
Reliable delivery to offline users (queued, delivered on reconnect)
Read receipts and typing indicators
Horizontal scaling across multiple server instances
Media attachments
Message ordering and idempotency (no duplicates on reconnect/retry)

Each of these is a small feature individually, but together they turn "just send a message" into a distributed systems problem.

The core pattern: WebSockets + a pub/sub layer

A single WebSocket server can hold persistent connections to your users, but the moment you run more than one server instance — which you will, the second you need to scale past a single box — you hit a fundamental problem: user A's connection lives on server 1, user B's connection lives on server 2. Server 1 has no direct way to push a message to a socket held by server 2.

The standard fix is a pub/sub layer sitting between your WebSocket servers, most commonly Redis Pub/Sub:

// server.js (simplified)
const io = require('socket.io')(httpServer);
const redis = require('ioredis');

const pub = new redis();
const sub = new redis();

sub.subscribe('dm-channel');

// When a message arrives from Redis, broadcast to any
// locally-connected socket for the recipient
sub.on('message', (channel, payload) => {
  const { recipientId, message } = JSON.parse(payload);
  io.to(recipientId).emit('new_message', message);
});

// When a user sends a DM
io.on('connection', (socket) => {
  socket.on('send_message', async (data) => {
    const message = await persistMessage(data); // write to DB first
    pub.publish('dm-channel', JSON.stringify({
      recipientId: data.recipientId,
      message,
    }));
  });
});

Every server instance subscribes to the same Redis channel, so it doesn't matter which server holds the recipient's socket connection — the message gets fanned out to all instances, and whichever one has that user connected delivers it. This is the pattern behind most production Socket.io deployments at scale, and it's the first thing to get right before adding any of the features below.

Handling offline delivery

Pub/sub solves the case where both users are online. It does nothing for the far more common case: the recipient isn't connected right now.

The fix is straightforward but easy to skip under deadline pressure — persist before you publish, never the other way around:

async function sendMessage(senderId, recipientId, content) {
  // 1. Write to durable storage FIRST
  const message = await db.messages.create({
    senderId, recipientId, content,
    status: 'sent',
    createdAt: new Date(),
  });

  // 2. Then attempt real-time delivery
  const delivered = await tryRealtimeDelivery(recipientId, message);

  if (!delivered) {
    // 3. Fall back to push notification
    await sendPushNotification(recipientId, message);
  }

  return message;
}

When the recipient reconnects, they fetch undelivered messages from the database rather than relying on having "missed" a real-time event — the real-time layer is an optimization on top of durable storage, not a replacement for it. This ordering matters: teams that build the real-time path first and treat persistence as an afterthought tend to lose messages under load or during deploys.

Read receipts and typing indicators without melting your server

These features feel small but generate a surprising amount of traffic if implemented naively — a typing indicator sent on every keystroke, for a group chat with 50 members, gets expensive fast.

Two practical fixes:

Debounce typing events client-side, and only re-broadcast if state actually changed:

let typingTimeout;
input.addEventListener('input', () => {
  if (!isTyping) {
    socket.emit('typing_start', { chatId });
    isTyping = true;
  }
  clearTimeout(typingTimeout);
  typingTimeout = setTimeout(() => {
    socket.emit('typing_stop', { chatId });
    isTyping = false;
  }, 2000);
});

Batch read receipts rather than firing one event per message read — mark a conversation "read up to message X" instead of acknowledging every individual message, which cuts an O(n) stream of receipt events down to a single state update per read session.

Idempotency: the bug that shows up only under load

WebSocket reconnects are inevitable — flaky mobile networks, app backgrounding, server restarts during deploys. If your client retries a "send message" call after a dropped connection without an idempotency key, you'll eventually ship duplicate messages to production, usually discovered by an annoyed beta user rather than in testing.

The fix is a client-generated idempotency key on every send:

socket.emit('send_message', {
  clientMessageId: uuidv4(), // generated once, reused on retry
  recipientId,
  content,
});

async function persistMessage(data) {
  // Upsert on clientMessageId prevents duplicates
  return db.messages.upsert({
    where: { clientMessageId: data.clientMessageId },
    create: { ...data },
    update: {}, // no-op if it already exists
  });
}

This is a small addition that prevents an entire category of "why did my message send twice" bug reports.

What this means for your build priority

If the retention data holds — and directionally, it matches what most social products observe — then the architectural takeaway isn't just "add DMs." It's that DMs deserve to be treated as core infrastructure, on par with your feed and auth system, rather than a checkbox feature squeezed in after the "real" product ships. That means:

Budgeting real engineering time for the pub/sub and persistence layer, not just a WebSocket happy path
Load-testing reconnect and offline-delivery paths before launch, not after complaints
Treating message delivery reliability as a metric you actually monitor, the same way you'd monitor feed load time

A feed brings people to your app. A conversation they're waiting on is what brings them back tomorrow — and that only works if the messaging layer underneath it doesn't drop messages, double-send them, or fall over the moment you scale past one server.

Want a follow-up piece diving deeper into one layer — message ordering/idempotency at scale, push notification fallback strategy, or scaling Redis Pub/Sub past a single Redis instance?

A Developer's Guide to the Amadeus API for Flight and Hotel Search

Lacey Glenn — Tue, 22 Sep 2026 10:10:33 +0000

If you're doing social media app development you're wiring up feeds and real-time chat. If you're doing travel app development, sooner or later you hit the same wall: where do actual flight and hotel prices come from? Most solo devs and small teams end up at the same answer — Amadeus for Developers, the self-service API layer on top of the GDS that powers a huge chunk of the travel industry.

This is the guide I wish I'd had before I burned a weekend misreading their docs. We'll cover authentication, flight search, hotel search, pricing, and the gotchas that aren't obvious until you hit them in production.

Why Amadeus (and when it's the wrong choice)

Amadeus's self-service tier is free in the test environment, with real (if occasionally stale) pricing data, and it covers flights, hotels, car rentals, points of interest, airport data, and more under one set of credentials. That's the appeal — one integration instead of five.

The tradeoffs: the test environment uses a cached/synthetic dataset that doesn't always match production pricing, the response shapes are dense (this is enterprise travel-industry JSON, not a clean REST-for-humans API), and moving to production requires a review process and negotiated pricing once you're past the free quota. If you only need flights, something like Skyscanner's or Duffel's API might be simpler. If you need flights and hotels and broader travel data under one roof, Amadeus is usually the pragmatic choice.

Getting Credentials

Sign up at developers.amadeus.com
Create an app in the dashboard — you'll get an API Key and API Secret
You're automatically in the test environment, which is free, rate-limited, and backed by cached data

Keep the key/secret out of source control. If you're prototyping, an .env file is fine; just don't commit it.

Authentication: OAuth2 Client Credentials

Every Amadeus call needs a bearer token. You get one by POSTing your credentials to the auth endpoint:

const axios = require('axios');
const qs = require('qs');

async function getAccessToken() {
  const response = await axios.post(
    'https://test.api.amadeus.com/v1/security/oauth2/token',
    qs.stringify({
      grant_type: 'client_credentials',
      client_id: process.env.AMADEUS_API_KEY,
      client_secret: process.env.AMADEUS_API_SECRET,
    }),
    { headers: { 'Content-Type': 'application/x-www-form-urlencoded' } }
  );

  return response.data.access_token; // expires in ~30 minutes
}

The token is short-lived (roughly 30 minutes), so don't fetch a new one per request — cache it and refresh when it's close to expiring:

let cachedToken = null;
let tokenExpiresAt = 0;

async function getToken() {
  if (cachedToken && Date.now() < tokenExpiresAt) return cachedToken;

  const res = await axios.post(
    'https://test.api.amadeus.com/v1/security/oauth2/token',
    qs.stringify({
      grant_type: 'client_credentials',
      client_id: process.env.AMADEUS_API_KEY,
      client_secret: process.env.AMADEUS_API_SECRET,
    }),
    { headers: { 'Content-Type': 'application/x-www-form-urlencoded' } }
  );

  cachedToken = res.data.access_token;
  tokenExpiresAt = Date.now() + (res.data.expires_in - 60) * 1000; // refresh 60s early
  return cachedToken;
}

If you'd rather skip the raw HTTP calls entirely, Amadeus maintains official SDKs for Node, Python, Java, and a few others that handle token refresh for you:

npm install amadeus

const Amadeus = require('amadeus');

const amadeus = new Amadeus({
  clientId: process.env.AMADEUS_API_KEY,
  clientSecret: process.env.AMADEUS_API_SECRET,
});

I'll show both raw and SDK versions below since plenty of people end up needing the raw calls anyway (custom caching, unsupported params, non-JS backends).

Flight Search

The core endpoint is Flight Offers Search (/v2/shopping/flight-offers).

Using the SDK:

amadeus.shopping.flightOffersSearch.get({
  originLocationCode: 'JFK',
  destinationLocationCode: 'CDG',
  departureDate: '2026-06-15',
  adults: '1',
  max: '10',
}).then(response => {
  console.log(response.data);
}).catch(error => {
  console.error(error.response ? error.response.result : error);
});

Raw HTTP equivalent:

async function searchFlights(origin, destination, date) {
  const token = await getToken();

  const response = await axios.get(
    'https://test.api.amadeus.com/v2/shopping/flight-offers',
    {
      headers: { Authorization: `Bearer ${token}` },
      params: {
        originLocationCode: origin,
        destinationLocationCode: destination,
        departureDate: date,
        adults: 1,
        max: 10,
      },
    }
  );

  return response.data.data;
}

A few parameter details that aren't obvious from the docs:

originLocationCode / destinationLocationCode are IATA codes, not city names — you'll want a separate lookup (Amadeus has an Airport & City Search endpoint) if you're taking free-text input from users
max caps the number of offers returned, but the API may still return fewer if there's limited inventory in the test dataset
Round trips just add returnDate — there's no separate "round trip" flag
travelClass accepts ECONOMY, PREMIUM_ECONOMY, BUSINESS, FIRST — omit it and you get mixed cabin results

The response is a data array of flight offers, each containing itineraries (with segments for each leg), a price object, and travelerPricings. This is where the density hits — a single round-trip offer with a connection can be 100+ lines of JSON. Budget real time for writing a normalizer that flattens this into something your frontend can actually render.

Flight Offers Price: Don't Skip This Step

Here's the part that trips people up. The price you get back from Flight Offers Search is not guaranteed — availability and fares shift constantly. Before you show a "book now" button or attempt to create an order, you need to re-confirm the price:

amadeus.shopping.flightOffers.pricing.post(
  JSON.stringify({
    data: {
      type: 'flight-offers-pricing',
      flightOffers: [selectedOffer], // the exact offer object from search results
    },
  })
).then(response => {
  console.log(response.data);
});

Skip this step and you'll eventually show users a price that's no longer bookable — which, in a travel app, is the single fastest way to erode trust. Always re-price immediately before checkout, not just at search time.

Hotel Search

Hotel search is a two-step process, which surprises a lot of people coming from the flight endpoints.

Step 1: Find hotel IDs in a city

amadeus.referenceData.locations.hotels.byCity.get({
  cityCode: 'PAR',
}).then(response => {
  console.log(response.data); // array of hotels with hotelId
});

Step 2: Get live offers for those hotel IDs

amadeus.shopping.hotelOffersSearch.get({
  hotelIds: 'MCLONGHM', // comma-separated hotel IDs from step 1
  checkInDate: '2026-07-10',
  checkOutDate: '2026-07-14',
  adults: '2',
}).then(response => {
  console.log(response.data);
});

Why two calls instead of one? The city-to-hotels endpoint uses relatively static reference data (cached, fast, cheap), while the offers endpoint hits live pricing/availability (slower, rate-limited more aggressively). Splitting them lets you cache the hotel list per city for hours or days while still hitting live pricing only when a user actually wants rates. If you fetch offers for every hotel in a city on every search, you'll blow through rate limits fast — batch your hotelIds and paginate.

Handling Errors and Rate Limits

The test environment rate-limits aggressively (expect low single-digit requests per second on some endpoints). Build in retry-with-backoff from day one rather than bolting it on after you get your first 429:

async function withRetry(fn, retries = 3, delay = 1000) {
  try {
    return await fn();
  } catch (err) {
    if (retries > 0 && err.response?.status === 429) {
      await new Promise(r => setTimeout(r, delay));
      return withRetry(fn, retries - 1, delay * 2);
    }
    throw err;
  }
}

Also worth knowing: Amadeus error responses come back with a structured errors array (code, title, detail) rather than a single message string — log the whole array during development, not just error.message, or you'll miss the actual reason a request failed.

Moving to Production

A few things change when you go live:

You apply for production access through the dashboard, which includes a review of your use case
Production URLs swap test.api.amadeus.com for api.amadeus.com
Pricing shifts from free-tier quotas to negotiated/metered rates depending on call volume
Test-environment hotel and flight data is synthetic-ish; production data reflects real GDS inventory, so re-test your UI against real responses — field completeness (missing images, sparse amenity data for smaller hotels) is more common than the test environment suggests

Where This Fits in a Larger Travel App

If you're building out a full travel app, Amadeus flight and hotel search is usually just one layer. In practice you'll pair it with:

A caching layer for search results (prices are volatile, but repeated identical searches within a short window don't need to hit the API again)
A normalization layer that converts Amadeus's nested itinerary/segment structure into whatever shape your frontend and database actually want
Separate booking/payment infrastructure — Amadeus can create flight orders via their Booking API, but most teams handle payment through Stripe or similar and only use Amadeus for the inventory side

None of that is Amadeus-specific complexity — it's the same architecture challenge you'd hit integrating any third-party inventory API into a real product. But it's worth scoping upfront rather than discovering it mid-sprint.

Building something with this? I'd genuinely like to hear what other travel APIs people are pairing with Amadeus — Duffel, Skyscanner, or something more niche.

Your App Just Lost Wi-Fi. Now What? Building an Offline-First Web App

Lacey Glenn — Mon, 21 Sep 2026 09:51:13 +0000

Service workers, IndexedDB, and Background Sync in one small, working pattern, with the failure cases most tutorials skip.

It's Friday evening, the shop is full, and the router just died.

If your app is a normal web app, the cashier now sees a spinner, then an error, then a queue of unhappy people. If you built it offline-first, nobody notices anything. Sales keep going through, and when the connection comes back, everything syncs quietly in the background.

The second version isn't magic. It's three browser features working together, plus one habit. Let's build it.

The mental model

Most tutorials teach these tools separately, which is why they're confusing. Here's what each one actually does:

Service worker: a script that sits between your app and the network. It makes sure the app itself loads with no internet.
IndexedDB: a database in the browser. It makes sure the data survives with no internet.
Background Sync: a way to say "run this when the connection returns, even if the tab is closed." It makes sure the upload eventually happens.

And the habit that ties them together:

Write locally first. Sync later. Never make the user wait on the network.

The UI talks only to IndexedDB. A separate process moves data between IndexedDB and the server. That single decision is what makes everything else easy.

Step 1: Make the app load offline

// app.js
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

Then cache the "app shell" (the HTML, JS, and CSS needed to boot) when the worker installs:

// sw.js
const CACHE = 'shell-v1';
const SHELL = ['/', '/index.html', '/app.js', '/styles.css'];

self.addEventListener('install', (e) => {
  e.waitUntil(caches.open(CACHE).then((c) => c.addAll(SHELL)));
  self.skipWaiting();
});

self.addEventListener('activate', (e) => {
  // Delete old caches when you bump the version
  e.waitUntil(
    caches.keys().then((keys) =>
      Promise.all(keys.filter((k) => k !== CACHE).map((k) => caches.delete(k)))
    )
  );
  self.clients.claim();
});

self.addEventListener('fetch', (e) => {
  const { request } = e;
  if (request.method !== 'GET') return;                   // only cache reads
  if (new URL(request.url).pathname.startsWith('/api/')) return; // API is handled by our own code

  // Cache first, network as fallback
  e.respondWith(caches.match(request).then((hit) => hit || fetch(request)));
});

Two things worth noticing. First, we deliberately skip /api/ requests. Your data layer shouldn't be hidden inside a generic cache rule. Second, bumping shell-v1 to shell-v2 is how you ship updates, and it's the part people forget.

Turn off your Wi-Fi and reload. The app should still open.

Step 2: Store data locally with IndexedDB

The raw IndexedDB API is famously awkward, so use the tiny idb wrapper, which gives you promises:

import { openDB } from 'idb';

export const dbPromise = openDB('shop', 1, {
  upgrade(db) {
    db.createObjectStore('products', { keyPath: 'id' });
    db.createObjectStore('outbox', { keyPath: 'id' });
  },
});

We have two stores. products is a local copy of data the app reads. outbox is a queue of things the user did that the server hasn't heard about yet.

Step 3: The outbox pattern

Here's the core idea. When the user does something (make a sale, save a note, submit a form), don't call the API. Write the action to the outbox and update the UI immediately.

export async function saveSale(sale) {
  const db = await dbPromise;

  await db.put('outbox', {
    id: crypto.randomUUID(),   // generated on the device, not by the server
    createdAt: Date.now(),
    payload: sale,
    status: 'pending',
  });

  requestSync();               // "please upload when you can"
}

Notice the ID is generated on the client. That's essential, and we'll come back to why in a moment.

From the user's point of view, the sale is done the instant this line finishes. No spinner, no network.

Step 4: Upload with Background Sync

Now we need something that empties the outbox. Background Sync lets the browser call your service worker when connectivity returns:

// app.js
async function requestSync() {
  const reg = await navigator.serviceWorker.ready;

  if ('sync' in reg) {
    await reg.sync.register('flush-outbox');
  } else {
    flushOutbox();   // fallback, see below
  }
}

window.addEventListener('online', requestSync);

And in the service worker:

// sw.js
importScripts('https://cdn.jsdelivr.net/npm/idb@8/build/umd.js');

async function flushOutbox() {
  const db = await idb.openDB('shop', 1);
  const items = await db.getAll('outbox');

  for (const item of items) {
    if (item.status === 'failed') continue;

    const res = await fetch('/api/sales', {          // a network error throws here
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'Idempotency-Key': item.id,
      },
      body: JSON.stringify(item.payload),
    });

    if (res.ok) {
      await db.delete('outbox', item.id);            // success: remove from queue
    } else if (res.status >= 400 && res.status < 500) {
      item.status = 'failed';                        // bad data: retrying won't help
      await db.put('outbox', item);
    } else {
      throw new Error('Server error');               // 5xx: let the browser retry
    }
  }
}

self.addEventListener('sync', (e) => {
  if (e.tag === 'flush-outbox') e.waitUntil(flushOutbox());
});

The important detail is throw. If the promise passed to waitUntil rejects, the browser treats the sync as failed and retries later with backoff. You get a retry loop for free.

Also note the split between error types. A network failure or a 5xx is temporary, so retry. A 4xx means the server rejected the data itself, and retrying forever would just block the queue. Mark it failed and surface it to a human.

Step 5: The bug that will bite you, duplicates

Imagine the request reaches the server, the server saves the sale, and the connection drops before the response arrives. Your app thinks it failed, so it retries. Now you've recorded the sale twice.

This is the reason for the Idempotency-Key header and the client-generated ID. The server must recognize a repeat:

// server (Express-style)
app.post('/api/sales', async (req, res) => {
  const key = req.get('Idempotency-Key');
  if (!key) return res.status(400).json({ error: 'Missing Idempotency-Key' });

  const existing = await db.sales.findByKey(key);
  if (existing) return res.status(200).json(existing);   // already processed, same answer

  const sale = await db.sales.create({ ...req.body, idempotencyKey: key });
  res.status(201).json(sale);
});

Back this with a unique constraint on the key in your database. A check in code alone can still race when two requests arrive at the same moment.

With this in place, retries are always safe. You can now be aggressive about retrying, which is exactly what unreliable networks require.

The catch: Background Sync isn't everywhere

Here's the honest part. Background Sync works in Chromium-based browsers (Chrome, Edge, and most Android browsers), but Safari and Firefox don't support it. So it should be an enhancement, not the only mechanism.

A solid fallback uses events you can rely on everywhere:

window.addEventListener('online', flushOutbox);   // connection returns
document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'visible') flushOutbox();
});
flushOutbox();                                    // on every app start

Put the flush logic in one plain script that both the page and the service worker can load, so you don't maintain two copies. With this, Chrome users get true background uploads, and everyone else syncs whenever the app is open. Neither group loses data.

Things that go wrong in production

1. Browsers can evict your storage. Under storage pressure, a browser may clear site data. Ask for durable storage so the outbox isn't the first thing to go:

if (navigator.storage?.persist) {
  await navigator.storage.persist();
}

2. Updating the service worker is tricky. A new worker waits until old tabs close. Decide deliberately how you'll handle this, for example by showing an "Update available" prompt rather than silently swapping code mid-sale.

3. Schema changes. IndexedDB upgrades run on user devices you can't see. Write the upgrade function to handle every old version, not just the previous one.

4. Don't trust the device clock. Use createdAt for ordering on the device, but let the server assign the authoritative time.

5. Show sync status. A small "3 sales waiting to upload" indicator turns anxiety into information. It's the cheapest trust feature you'll ever add.

How to test it properly

In Chrome DevTools, open Application → Service Workers and tick Offline.
Use Network → Slow 3G to simulate a bad connection.
Under Application → Background Services → Background Sync, you can record and trigger sync events.
Most importantly, test the nasty case: kill the connection mid-request. That's where duplicate bugs hide.

The takeaway

Offline support isn't a feature you add at the end. It's a decision about where the source of truth lives while the user is working: the device first, the server eventually.

Once you make that decision, the rest follows. The UI talks to a local database. A queue carries changes upward. Idempotency makes retries safe. The service worker keeps the lights on.

The result is an app that treats a dead router as a minor inconvenience instead of an outage, and users who never learn how close it came to failing.

Want this as a Markdown file ready to paste into dev.to (with front-matter tags), or a companion repo layout with a minimal working demo?

Why Every Generation Thinks the Internet "Used to Be Better"

Lacey Glenn — Thu, 17 Sep 2026 13:39:54 +0000

Tracing the same complaint across 30 years of forums, feeds, and false golden ages

There is a comment you can find in almost any online space, in almost any year since 1993: it wasn't like this before. Before the newbies. Before the ads. Before the algorithm. Before "everyone" showed up and ruined it.

The remarkable thing isn't that people say this. It's that they've been saying it, in nearly identical language, for three decades — about completely different internets.

The pattern has a name, and it's older than you think

In September 1993, AOL gave its subscribers access to Usenet, the sprawling network of discussion groups that had, until then, been populated mostly by university students and researchers. Every autumn before that, a new class of undergrads had arrived, asked the same beginner questions, and been absorbed within a few weeks as they learned the norms. Old-timers called it "September."

AOL's rollout broke the pattern. Now newcomers arrived constantly, in volumes the old culture couldn't absorb or educate fast enough. Longtime users started calling it the Eternal September — the month that never ended, the moment the internet stopped belonging to the people who'd built its culture.

This is worth sitting with, because it means the founding complaint about the internet getting worse wasn't about smartphones, or social media, or algorithms. It was about too many people arriving too fast for a culture to metabolize them. Everything that came after is a variation on that same anxiety.

Every decade gets its own "before"

The 1990s golden age, as remembered by the people who were there, was Usenet and early web forums — text-heavy, slow, populated by a self-selecting group of the technically curious. Getting online required enough effort that it filtered out casual users. The nostalgia here is really nostalgia for exclusivity, though it's rarely described that way.

The early-2000s golden age was blogs and forums — LiveJournal, phpBB communities, the first wave of Wikipedia. People who came up in this era remember a web that felt handmade, where a "community" was a few hundred people who all knew each other's usernames. The complaint that killed this era, in real time, was the arrival of easy publishing tools and broadband: suddenly everyone could have a blog, and the people who'd been writing since 2001 felt outnumbered.

The Web 2.0 golden age was the social web before it consolidated — MySpace profiles you coded yourself, the early feed of Facebook when it was chronological and only for people you actually knew, the first few years of Twitter when it felt like a clubhouse of writers and journalists. This era's death, as its mourners tell it, came from algorithmic feeds and the arrival of brands, influencers, and eventually bots.

The mid-2010s golden age — the one a lot of people in their twenties and thirties are nostalgic for right now — was peak Tumblr, early Instagram, Vine, the specific texture of a web that hadn't yet been fully optimized for engagement metrics. Its death is blamed on the same mechanism as the one before it: algorithmic ranking, ad load, and platforms tuning themselves for time-on-site rather than user satisfaction.

Notice the shape. Every single "golden age" is remembered as smaller, slower, and more sincere than what replaced it. And every single ending is blamed on the same two forces: more people arriving, and platforms optimizing for something other than the users' experience.

Three things are actually happening at once — and they get conflated

The reason this complaint feels true every single time, to every single generation, is that it's actually three distinct phenomena bundled into one feeling.

First, there's a real economic and design shift. Ad-supported platforms do change over time, usually for the worse from the user's perspective. The writer Cory Doctorow coined the term "enshittification" for this specific pattern: a platform starts by being good to users to attract them, then shifts value toward business customers (advertisers, sellers) once users are locked in, then finally extracts value for shareholders at the expense of everyone else. This is a real, documented business dynamic — not nostalgia. Early Amazon really did subsidize prices to build a user base before raising them. Early Facebook really did have a chronological feed before algorithmic ranking maximized ad exposure. This part of the complaint is often correct.

Second, there's a scale effect that has nothing to do with corporate greed. Any space that grows from a thousand people to a hundred million people will feel different, even with zero changes to its business model, because culture and norms are load-bearing structures that only work at certain sizes. A dinner party and a stadium concert are different experiences not because the stadium is "worse," but because the mechanics of a thousand-person crowd are categorically different from an eight-person conversation. Early internet communities felt intimate because they were, structurally, small. That intimacy was never going to survive success — not because of any villain, but because of arithmetic.

Third — and this is the one people like least to hear — there's you. The person who joined a platform at 19 and left at 29 experienced the platform's actual evolution, but they also experienced their own evolution: from someone with unlimited free time and low stakes to someone with a job, relationships, and a shrinking tolerance for nonsense. Some of what feels like "the internet got worse" is "I got less available to be delighted by novelty." Psychologists have long noted that the intensity of nostalgia tends to peak for the cultural artifacts of adolescence and early adulthood — the phenomenon shows up for music, food, and slang, not just platforms. The internet you fell in love with probably corresponded with a specific window in your own life that was never coming back regardless of what any platform did.

The Eternal September never actually ended

Here's the uncomfortable twist: the Eternal September framing implies a one-time event — a before and after. But the actual pattern is that it happens again, to a smaller population, every single time a space grows. Usenet old-timers felt it about AOL users. Early bloggers felt it about MySpace teenagers. Early Twitter felt it about the "normies" who arrived after Ellen's celebrity selfie. TikTok's earliest adopters felt it the moment it stopped being a lip-sync app for teenagers and became the default video platform for everyone, including their parents.

Each of these groups was right that their experience of the platform changed. Where they tend to be wrong is in assuming this was a unique historical rupture rather than the same structural event that has happened, on schedule, to every online space that ever grew.

What this means if you're feeling it right now

If you're someone who thinks "the internet used to be better" — and if you're old enough to be reading a Medium essay, you probably are — the honest version of that feeling has three separate parts worth untangling:

Some of what you're mourning is a real, documented shift in incentives as platforms matured from growth mode to extraction mode. That part is a legitimate critique, and it's worth directing at regulation, competition, and interoperability rather than nostalgia alone.

Some of what you're mourning is simply what happens to any small culture that succeeds. It's not corruptible or fixable; it's the cost of the thing you loved being good enough that other people wanted it too.

And some of what you're mourning isn't the internet at all. It's a version of yourself who had the time, the attention span, and the low stakes required to fall in love with a website. That version of you is not coming back, no matter which platform you open.

The internet isn't in perpetual decline. It's in perpetual turnover — a machine that manufactures golden ages and then, with total reliability, produces the generation that mourns their passing. The only unusual thing about your version of this complaint is that you think it's the first time it's happened.

Designing a Microservices Architecture for a Video Streaming Platform

Lacey Glenn — Wed, 16 Sep 2026 13:11:24 +0000

Most tutorials on video streaming app development start and end with "how to play a video in the browser." That's the easy 10% of the problem. The hard part — the part that determines whether your platform survives contact with real traffic — is everything happening behind the player: ingestion, transcoding, metadata, recommendations, billing, and delivery, all working together without falling over at scale.

This is a breakdown of how to think about microservices architecture for a video streaming platform, based on the patterns most production systems converge on regardless of stack.

Why Monolith-First Doesn't Work Here (Usually)
For most products, "start with a monolith" is good advice. Streaming platforms are one of the exceptions, because the workloads involved are so different from each other:

Video transcoding is CPU/GPU-bound and bursty
Live streaming is latency-sensitive and stateful
User authentication and billing need strong consistency
Search and recommendations are read-heavy and tolerant of eventual consistency
Content delivery needs to be geographically distributed
Cramming all of that into one deployable unit means your transcoding queue backing up can take down your login page. Splitting these concerns early — even in an MVP — saves you from a painful rewrite later.

Core Services in a Streaming Platform
Here's a practical service breakdown that most streaming architectures end up with, whether they call it "microservices" explicitly or not.

Ingestion Service Handles raw video upload from content creators or internal teams. Responsibilities: validating file format, virus/malware scanning, writing to object storage (S3 or equivalent), and publishing an event to kick off transcoding.

POST /v1/uploads
→ validate file
→ store raw file in object storage
→ emit "video.uploaded" event to message queue

Transcoding Service Consumes upload events and converts raw video into multiple resolutions and bitrates (adaptive bitrate streaming formats like HLS or DASH). This is the most resource-intensive service and should scale independently — usually on a queue-based worker pool with autoscaling tied to queue depth, not request volume.

Key design decision: transcoding should be idempotent and resumable. A crashed worker mid-job shouldn't corrupt output or require reprocessing the entire file from scratch.

Metadata Service
Owns structured data about each title: title, description, cast, genre tags, scene markers, duration, available resolutions. This service is read-heavy and benefits from a separate read-optimized store (or CQRS pattern) since it's queried far more often than it's written to.
Playback/Streaming Service
Generates signed playback URLs, manages manifest files (.m3u8/.mpd), and handles DRM license requests. This service sits closest to the CDN edge and needs to be stateless and horizontally scalable — it's on the critical path for every single play event.
User & Auth Service
Handles authentication, session management, and profile data. Needs strong consistency and is a good candidate for a traditional relational database, unlike most of the rest of the stack.
Recommendation Service
Consumes watch history events and produces personalized rankings. This is typically eventually consistent — a slightly stale recommendation is an acceptable trade-off for lower latency and simpler infrastructure. Often built with its own data pipeline (event stream → feature store → model serving).
Billing/Subscription Service
Isolated deliberately. Payment processing has its own compliance requirements (PCI-DSS) and should never share a database or deployment with content-serving services. Keep the blast radius of a billing bug as small as possible.
Analytics/Telemetry Service
Ingests playback events (buffering, quality switches, watch duration, drop-off points) at high volume. Usually backed by a time-series or event-streaming system (Kafka, Kinesis) rather than a traditional database, since the write volume dwarfs every other service.

Communication Patterns Between Services
Two patterns tend to dominate in production streaming architectures:

Synchronous (REST/gRPC) — used where the caller needs an immediate response: auth checks, generating a playback URL, fetching metadata for a detail page.

Asynchronous (event-driven via message queue) — used for anything that doesn't need to block the user: transcoding kickoff, analytics ingestion, recommendation model updates, sending a "your video is ready" notification.

A common mistake in early video streaming app development is making transcoding synchronous — having the upload endpoint wait for transcoding to finish before responding. This couples an unpredictable, long-running job to a user-facing request and will eventually time out or crash under load. Decouple it with a queue from day one.

Data Storage: One Size Does Not Fit All
Resist the urge to put everything in one database. A workable split looks like:

Data Type Storage Choice Why
Raw & transcoded video files Object storage (S3/GCS) Cheap, durable, integrates natively with CDNs
Metadata (titles, tags) Relational DB or document store Structured, queried frequently, moderate write volume
User accounts & sessions Relational DB Needs strong consistency
Watch history & events Event stream + time-series/data warehouse Extremely high write volume, analytical queries
Recommendations cache In-memory store (Redis) Needs sub-millisecond read latency
CDN and Edge Delivery
No microservices discussion is complete without addressing delivery, since it's often the largest line item in infrastructure cost. The playback service should never serve video bytes directly — it issues signed manifest URLs, and a CDN handles the actual byte delivery from edge locations close to the viewer. Cache video segments aggressively; cache manifests more cautiously since they can change (e.g., ad insertion points, live stream updates).

Common Pitfalls
Over-splitting early. Not every function needs to be its own service on day one. Start with a handful of clearly bounded services (ingestion+transcoding, metadata+playback, user+billing) and split further as team size and traffic demand it.
Ignoring backpressure. Transcoding queues can back up badly during traffic spikes (a viral upload, a launch day). Design autoscaling and queue monitoring in from the start, not as a fix after an outage.
Tight coupling through shared databases. If two services read/write the same tables directly, you don't actually have microservices — you have a distributed monolith with extra network hops and none of the benefits.
Underinvesting in observability. With this many moving parts, distributed tracing (OpenTelemetry or similar) isn't optional. When a user reports buffering, you need to trace the request across transcoding, playback, and CDN layers to find the actual cause.
Wrapping Up
A microservices architecture for a streaming platform isn't about chasing a trendy pattern — it's a direct response to how different the workloads are: bursty CPU-bound transcoding, latency-sensitive playback, high-volume analytics, and strongly consistent billing all pulling in different directions. Getting the service boundaries and communication patterns right early is one of the highest-leverage decisions in video streaming app development, because it's far cheaper to draw those lines correctly at the start than to untangle a monolith once you're serving real traffic.

If you're building your first version, don't aim for a fully distributed system on day one — aim for clean boundaries that let you split services out later without a rewrite.

Why Your Social App's Notification System Will Break at 10K Users (And How to Fix It Before It Happens)

Lacey Glenn — Tue, 15 Sep 2026 09:56:11 +0000

If you've ever shipped a "like," "comment," or "follow" notification feature, you know how deceptively simple it looks in the demo. One user does something, another user gets pinged. Done.

Then you hit 10,000 users and everything falls apart at once: notifications arrive 20 minutes late, your push provider starts throttling you, your database CPU spikes every time someone posts, and your on-call engineer is debugging a queue that's somehow 400,000 jobs deep.

This isn't a hypothetical. It's the single most predictable failure pattern in social app backends, and it happens because notification systems are usually built for the happy path of one user, not the fan-out path of thousands. Here's exactly where it breaks, and how to fix each piece before it becomes a 2 a.m. incident.

Why 10K Users Specifically?

There's nothing magic about the number 10,000 — it's just where three things usually converge for the first time:

Your average "popular" user now has enough followers that a single action fans out to hundreds or thousands of notification events
Your traffic is high enough that naive polling or synchronous writes start queuing up
You're still on the architecture you built in week one, because it worked fine until now

Below are the five places that break first, roughly in the order teams discover them.

1. The Fan-Out Problem: One Action, Thousands of Writes

The naive version:

// DON'T DO THIS AT SCALE
async function onNewPost(post) {
  const followers = await db.query(
    'SELECT user_id FROM followers WHERE following_id = $1',
    [post.authorId]
  );

  for (const follower of followers) {
    await db.insert('notifications', {
      userId: follower.user_id,
      type: 'new_post',
      postId: post.id,
    });
    await pushService.send(follower.user_id, 'New post!');
  }
}

This works beautifully for a user with 20 followers. For a user with 50,000 followers, this is 50,000 sequential database writes and 50,000 sequential HTTP calls to your push provider — inside a single request handler. Your API times out, your DB connection pool exhausts, and every other request queues behind it.

Why it breaks specifically at 10K users: early on, nobody has enough followers for fan-out to matter. Once a handful of accounts become "popular" relative to your user base, their actions become mini denial-of-service events against your own infrastructure.

The fix — push the fan-out off the request path:

// Producer: just enqueue, respond fast
async function onNewPost(post) {
  await queue.publish('fan-out-notifications', { postId: post.id });
  return; // API responds in milliseconds
}

// Consumer: does the heavy lifting asynchronously, in batches
async function fanOutWorker({ postId }) {
  const post = await db.getPost(postId);
  const followerIds = await db.getFollowerIds(post.authorId); // batched query

  const BATCH_SIZE = 500;
  for (let i = 0; i < followerIds.length; i += BATCH_SIZE) {
    const batch = followerIds.slice(i, i + BATCH_SIZE);
    await db.bulkInsertNotifications(batch.map(userId => ({
      userId, type: 'new_post', postId,
    })));
    await queue.publish('send-push-batch', { userIds: batch, postId });
  }
}

The API request now does one cheap thing (publish a message) instead of one expensive thing (fan out synchronously). Everything expensive happens in a worker that can scale horizontally and retry independently of your user-facing traffic.

2. The N+1 Query You Don't Notice Until It's Too Late

Fetching a user's device tokens one row at a time is invisible at low volume and catastrophic at scale:

// N+1 pattern — one query per follower
for (const follower of followers) {
  const tokens = await db.query(
    'SELECT device_token FROM devices WHERE user_id = $1',
    [follower.user_id]
  );
}

At 500 followers, that's 500 round-trips to the database for a single post. Multiply by concurrent posts and you've turned your database into the bottleneck for a feature that has nothing to do with your core data model.

The fix: batch it.

const tokens = await db.query(
  'SELECT user_id, device_token FROM devices WHERE user_id = ANY($1)',
  [followerIds]
);

One query, one round-trip, regardless of whether you're notifying 10 people or 10,000.

3. Push Provider Rate Limits You Didn't Know Existed

FCM and APNs both have throughput limits, and they will silently drop or delay your notifications if you slam them with individual requests instead of using their batch/multicast APIs.

// Inefficient: one HTTP call per device
for (const token of tokens) {
  await fcm.send({ token, notification: { title: 'New post!' } });
}

At scale this hits rate limits, and worse, a single slow or failed call blocks the loop if you're not handling concurrency correctly.

The fix: use multicast/batch sending, and respect the provider's batch size limits (FCM caps multicast at 500 tokens per call):

const BATCH_SIZE = 500;
for (let i = 0; i < tokens.length; i += BATCH_SIZE) {
  const batch = tokens.slice(i, i + BATCH_SIZE);
  const response = await fcm.sendMulticast({
    tokens: batch,
    notification: { title: 'New post!' },
  });

  // Critical: prune dead tokens so you stop paying this cost forever
  response.responses.forEach((res, idx) => {
    if (!res.success && res.error?.code === 'messaging/registration-token-not-registered') {
      deadTokens.push(batch[idx]);
    }
  });
}
await db.deleteDeviceTokens(deadTokens);

That last part — pruning dead tokens — is the piece almost every team skips, and it's why notification volume keeps growing even as engagement doesn't: you're paying to "notify" phones that were factory-reset eight months ago.

4. No Backpressure: The Queue That Ate Your Server

Once you move to a queue (good), the next failure mode is not thinking about backpressure (bad). If your worker can process 200 jobs/second but a viral post generates 50,000 fan-out jobs instantly, you need the queue to absorb that burst — not your worker process to fall over trying to drain it all at once.

Symptoms this is happening to you:

Memory usage on worker nodes climbs steadily and never recovers
Notifications for older events "jump the queue" in front of newer, more relevant ones
One viral post delays every other user's notifications by 30+ minutes

The fix — bound your concurrency and prioritize:

// Using a library like BullMQ
const worker = new Worker('send-push-batch', processJob, {
  concurrency: 20,          // bounded, not unlimited
  limiter: {
    max: 1000,
    duration: 1000,         // 1000 jobs/sec ceiling, matches provider limits
  },
});

// Separate high-priority queue for time-sensitive notifications
// (DMs, mentions) so they don't sit behind a mass fan-out
await queue.add('send-push-batch', data, { priority: isDirectMessage ? 1 : 10 });

Backpressure isn't a nice-to-have at scale — it's the difference between "the queue is a bit backed up" and "the queue took down the box it runs on."

5. Real-Time Delivery: The WebSocket Server That Can't Scale Out

If you're pushing live in-app notifications over WebSockets, there's a subtler trap: a naive implementation keeps each user's connection and the logic to notify them on the same server process, in memory.

// Breaks the moment you run more than one server instance
const connectedUsers = new Map(); // userId -> socket

function notifyUser(userId, payload) {
  const socket = connectedUsers.get(userId);
  if (socket) socket.emit('notification', payload);
}

This works great with one server and falls apart the moment you need two, because the user your worker wants to notify might be connected to a different instance that has no idea about that in-memory map.

The fix — decouple "who's connected" from "who's sending":

// Each server subscribes to a shared pub/sub channel (Redis, NATS, etc.)
redisSub.subscribe('notifications');

redisSub.on('message', (channel, message) => {
  const { userId, payload } = JSON.parse(message);
  const socket = connectedUsers.get(userId); // only checks local connections
  if (socket) socket.emit('notification', payload);
});

// Any server, anywhere, can trigger a notification
function notifyUser(userId, payload) {
  redisPub.publish('notifications', JSON.stringify({ userId, payload }));
}

Now it doesn't matter which server instance holds the user's socket — every instance is listening, and only the one holding the actual connection acts on it. This is what lets you add a second, third, or tenth WebSocket server without a rewrite.

The Architecture That Actually Scales

Putting it together, a notification system that survives past 10K users generally looks like this:

[API request] --> [Queue: fan-out-notifications]
                          |
                          v
                 [Worker: batch DB writes]
                          |
                          v
        +-----------------+------------------+
        |                                     |
        v                                     v
[Queue: send-push-batch]           [Pub/Sub: realtime-notifications]
        |                                     |
        v                                     v
[Worker: batched provider calls]   [WebSocket servers, any instance]
        |
        v
[Prune dead tokens back to DB]

The common thread across every fix above: get expensive work off the request path, batch everything that touches an external system, and never assume state lives on just one server.

The Checklist Before You Hit 10K Users

[ ] Fan-out happens in a background worker, not inside the API request
[ ] Follower/device-token lookups are batched, never looped one row at a time
[ ] Push sends use the provider's multicast/batch endpoints, respecting size limits
[ ] Failed/dead device tokens are pruned automatically, not left to accumulate forever
[ ] Your queue has bounded concurrency and a rate limiter matching your provider's real limits
[ ] Time-sensitive notifications (DMs, mentions) are prioritized over mass fan-out events
[ ] Real-time delivery uses pub/sub so it works across multiple server instances, not just one

None of these fixes are exotic — they're all standard distributed-systems patterns. The trick is applying them before your first viral post, not during the incident review after it.

Have you hit a different notification scaling wall — email digest storms, SMS costs exploding, or something else entirely? I'd love to hear what broke first for you in the comments.

Build a Rate Limiter From Scratch in 50 Lines

Lacey Glenn — Mon, 14 Sep 2026 11:20:33 +0000

Every serious API needs rate limiting. Most people reach for a library the moment they hear "rate limiter" — express-rate-limit, bottleneck, some Redis-backed package with a dozen config options they'll never touch.

But the algorithm underneath almost all of them — token bucket — is genuinely simple. You can write a correct, production-usable in-memory version in about 50 lines of JavaScript, no dependencies. Understanding it from scratch also means you'll actually know what those library config options are doing instead of copy-pasting them.

Let's build it.

The idea, in one paragraph

Imagine a bucket that holds tokens. Every request needs one token to go through. The bucket refills at a steady rate (say, 10 tokens per second) up to some maximum capacity. If the bucket is empty when a request arrives, the request gets rejected (or delayed). That's it. That's the whole algorithm — the rest is just implementation detail.

The reason token bucket is so popular over simpler approaches ("max N requests per fixed minute") is that it naturally allows bursts while still enforcing an average rate. A user who's been idle can burst up to the bucket's capacity, then has to slow down to the refill rate — which matches how real traffic actually behaves.

The core implementation

class TokenBucket {
  constructor({ capacity, refillRatePerSec }) {
    this.capacity = capacity;           // max tokens the bucket can hold
    this.tokens = capacity;             // start full
    this.refillRatePerSec = refillRatePerSec;
    this.lastRefillTimestamp = Date.now();
  }

  _refill() {
    const now = Date.now();
    const elapsedSeconds = (now - this.lastRefillTimestamp) / 1000;
    const tokensToAdd = elapsedSeconds * this.refillRatePerSec;

    if (tokensToAdd > 0) {
      this.tokens = Math.min(this.capacity, this.tokens + tokensToAdd);
      this.lastRefillTimestamp = now;
    }
  }

  tryConsume(tokensRequested = 1) {
    this._refill();

    if (this.tokens >= tokensRequested) {
      this.tokens -= tokensRequested;
      return true;
    }
    return false;
  }
}

That's the entire algorithm — about 25 lines. No timers, no setInterval, no background refill loop. The trick is lazy refill: instead of a ticking clock adding tokens every N milliseconds, we just calculate "how many tokens should have been added since the last check" whenever a request actually comes in. This is simpler, cheaper, and has no drift.

Wrapping it for per-user rate limiting

A single bucket rate-limits your entire server, which isn't usually what you want. In practice you need one bucket per user (or per IP, per API key, etc.). Here's a manager class that handles that:

class RateLimiter {
  constructor({ capacity, refillRatePerSec }) {
    this.capacity = capacity;
    this.refillRatePerSec = refillRatePerSec;
    this.buckets = new Map(); // key -> TokenBucket
  }

  _getBucket(key) {
    if (!this.buckets.has(key)) {
      this.buckets.set(
        key,
        new TokenBucket({
          capacity: this.capacity,
          refillRatePerSec: this.refillRatePerSec,
        })
      );
    }
    return this.buckets.get(key);
  }

  allow(key, cost = 1) {
    return this._getBucket(key).tryConsume(cost);
  }
}

And that's the full implementation — right around 50 lines total, zero dependencies.

Using it as Express middleware

Here's where it becomes actually useful:

const limiter = new RateLimiter({ capacity: 10, refillRatePerSec: 2 });

function rateLimitMiddleware(req, res, next) {
  const key = req.ip; // or req.user.id, or an API key from headers

  if (limiter.allow(key)) {
    next();
  } else {
    res.status(429).json({ error: "Too many requests. Slow down." });
  }
}

app.use("/api/", rateLimitMiddleware);

With capacity: 10 and refillRatePerSec: 2, each client can burst up to 10 requests instantly, then is limited to a sustained 2 requests/second after that. Tune both numbers to match your actual traffic patterns — capacity controls burst tolerance, refill rate controls the long-run average.

Testing it actually works

A quick sanity check, no test framework needed:

const bucket = new TokenBucket({ capacity: 5, refillRatePerSec: 1 });

// Burst: first 5 requests succeed immediately
for (let i = 0; i < 5; i++) {
  console.log(bucket.tryConsume()); // true x5
}

// 6th request fails — bucket is empty
console.log(bucket.tryConsume()); // false

// Wait ~1 second, one token refills
setTimeout(() => {
  console.log(bucket.tryConsume()); // true
  console.log(bucket.tryConsume()); // false again
}, 1000);

Run that and you'll see exactly the burst-then-throttle behavior we designed for.

The catch: this only works on a single instance

This in-memory version resets if your process restarts, and — more importantly — each server instance has its own separate buckets. If you're running 4 instances behind a load balancer, a client could get 4x their intended limit by hitting different instances.

For a single-server app, side project, or internal tool, this is completely fine as-is. For a distributed production system, you need the buckets to live somewhere shared — which is exactly what Redis-backed rate limiters (like rate-limiter-flexible) are doing under the hood: the same token bucket math, just with INCR and EXPIRE commands against a shared store instead of a local Map. The algorithm you just wrote doesn't change — only where the state lives does.

A quick comparison to other approaches

You'll sometimes see fixed window ("max 100 requests per clock-minute") or sliding window log (timestamp array per user) used instead. Fixed window is simpler but has a nasty edge case: a client can send 100 requests at 11:00:59 and another 100 at 11:01:00 — 200 requests in two seconds, technically within limits. Token bucket doesn't have this problem because tokens refill continuously, not in discrete resets.

Sliding window log is more precise than token bucket but costs more memory (you're storing every timestamp, not just a number). For most APIs, token bucket is the sweet spot: simple, cheap, and burst-tolerant without being exploitable.

Wrapping up

The full rate limiter — bucket logic, per-user manager, and middleware wiring — comes in under 50 lines and has zero external dependencies. You now know exactly what's happening every time you set windowMs and max in some rate-limiting library, because you just built the thing those options configure.

If you want to take it further: swap the in-memory Map for Redis calls to make it distributed, or add a Retry-After header calculated from (tokensRequested - this.tokens) / this.refillRatePerSec so clients know exactly how long to back off.

What rate-limiting edge case has bitten you in production? Drop it in the comments — I'll bet it's a fixed-window bug.

Caching Strategies for Travel Apps: Reducing API Calls Without Stale Data

Lacey Glenn — Fri, 11 Sep 2026 12:17:32 +0000

If you've built anything on top of a flight, hotel, or car rental API, you've run into this tension fast: third-party travel APIs are slow, rate-limited, and often billed per call — but the data behind them (prices, seat availability, room inventory) changes constantly. Cache too aggressively and you show a user a $340 flight that's actually $410 by the time they click "Book." Don't cache enough and you're burning through your API quota, eating latency on every search, and probably getting throttled during your busiest traffic (hello, holiday booking season).

This isn't a generic "just add Redis" problem. Travel data has wildly different volatility depending on what it is, and a caching strategy that treats all of it the same way will either be too stale or too expensive. Here's how to actually think about it.

Step 1: Classify Your Data by Volatility

Before picking a caching technique, sort what you're caching into buckets based on how often it actually changes:

Data Type	Volatility	Safe TTL Range
Airport/city metadata, airline names	Near-static	Days to weeks
Hotel amenities, descriptions, photos	Low	Hours to a day
Destination content, travel guides	Low	Hours to a day
Flight schedules (not prices)	Moderate	15–60 minutes
Hotel room availability	High	1–5 minutes
Flight seat availability	High	1–5 minutes
Live pricing	Very high	Seconds, or don't cache at all
Booking confirmation status	Never cache	N/A — always live

This table alone solves most of the "stale data" fear. The mistake isn't caching travel data — it's caching all of it with one blanket TTL. Treat metadata and pricing as fundamentally different problems.

Strategy 1: Layered TTL Caching

The simplest effective pattern is a short-TTL cache in front of your most volatile endpoints, with a longer TTL for stable reference data.

// Simplified example using Redis
const CACHE_TTL = {
  airportMetadata: 60 * 60 * 24 * 7, // 7 days
  hotelDetails: 60 * 60 * 6,          // 6 hours
  flightAvailability: 60 * 2,         // 2 minutes
  livePricing: 15,                    // 15 seconds
};

async function getCached(key, ttlSeconds, fetchFn) {
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const fresh = await fetchFn();
  await redis.set(key, JSON.stringify(fresh), 'EX', ttlSeconds);
  return fresh;
}

// Usage
const flightResults = await getCached(
  `flights:${origin}:${destination}:${date}`,
  CACHE_TTL.flightAvailability,
  () => searchFlightsAPI(origin, destination, date)
);

This gets you 80% of the benefit with almost no complexity. The remaining 20% — avoiding the moment a user books a stale price — needs one more layer.

Strategy 2: Cache for Search, Never for Booking

This is the single most important rule in travel app caching: cached data is fine for search and display, never fine for the final booking confirmation step.

The pattern that works well in practice:

User searches → results come from cache (fast, cheap)
User selects a flight/room → re-validate that specific item against the live API before showing the booking screen
If the price or availability changed, show the user the update transparently ("Price updated: $340 → $355") rather than silently booking at a wrong price
Only proceed to payment once you have a live-confirmed price and availability

async function initiateBooking(flightId) {
  // Never trust the cached price at this stage
  const liveData = await flightAPI.getLiveOffer(flightId);

  if (liveData.price !== cachedPrice) {
    return {
      status: 'price_changed',
      oldPrice: cachedPrice,
      newPrice: liveData.price,
    };
  }

  return proceedToPayment(liveData);
}

This single pattern eliminates almost all of the "we showed a stale price" complaints, because the cache is only ever responsible for the browsing experience — not the transaction.

Strategy 3: Stale-While-Revalidate for Search Results

For search-heavy screens, users tolerate very slightly outdated results far better than they tolerate a slow spinner. The stale-while-revalidate pattern serves cached data immediately while kicking off a background refresh:

async function staleWhileRevalidate(key, ttl, staleTtl, fetchFn) {
  const cached = await redis.get(key);

  if (cached) {
    const { data, timestamp } = JSON.parse(cached);
    const age = Date.now() - timestamp;

    if (age < ttl) {
      return data; // Fresh enough, return immediately
    }

    if (age < staleTtl) {
      // Serve stale data now, refresh in the background
      refreshInBackground(key, fetchFn);
      return data;
    }
  }

  // No cache or too stale — fetch synchronously
  const fresh = await fetchFn();
  await redis.set(key, JSON.stringify({ data: fresh, timestamp: Date.now() }));
  return fresh;
}

function refreshInBackground(key, fetchFn) {
  fetchFn().then(fresh => {
    redis.set(key, JSON.stringify({ data: fresh, timestamp: Date.now() }));
  }).catch(err => console.error('Background refresh failed', err));
}

This is what makes search feel instant even when the underlying API is slow — the user gets a response in milliseconds while the next search benefits from fresher data.

Strategy 4: Guard Against Cache Stampedes

Here's a failure mode that catches teams off guard: a popular route's cache entry expires, and 500 concurrent users hit your backend at the same moment, all triggering a fresh API call simultaneously. This can blow through rate limits or spike your API bill in seconds.

The fix is a simple lock/mutex around the refresh:

async function getCachedWithLock(key, ttl, fetchFn) {
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const lockKey = `lock:${key}`;
  const gotLock = await redis.set(lockKey, '1', 'NX', 'EX', 10);

  if (!gotLock) {
    // Someone else is already fetching — wait briefly and retry from cache
    await sleep(200);
    return getCachedWithLock(key, ttl, fetchFn);
  }

  try {
    const fresh = await fetchFn();
    await redis.set(key, JSON.stringify(fresh), 'EX', ttl);
    return fresh;
  } finally {
    await redis.del(lockKey);
  }
}

This ensures only one request actually hits the upstream API while everyone else waits milliseconds for the result, instead of every concurrent request independently hammering a rate-limited endpoint.

Strategy 5: Edge Caching for Static-ish Content

Not everything belongs in Redis. Airport metadata, city info, hotel photos, and destination guides are perfect candidates for CDN-level edge caching with standard HTTP cache headers:

// Express example
app.get('/api/airports/:code', (req, res) => {
  res.set('Cache-Control', 'public, max-age=604800'); // 7 days
  res.json(getAirportMetadata(req.params.code));
});

Pushing this to the CDN edge means these requests never even reach your application servers, which matters a lot for global travel apps with users spread across continents.

Strategy 6: Predictive Pre-Warming for Popular Routes

If you have visibility into your traffic patterns, you can pre-warm the cache for high-traffic routes (NYC–LA, London–Dubai) before users even search for them — using a scheduled job rather than waiting for the first user to trigger a cold cache miss.

// Runs every few minutes for top routes
const POPULAR_ROUTES = [
  ['JFK', 'LAX'], ['LHR', 'DXB'], ['SFO', 'NRT'],
];

async function prewarmCache() {
  for (const [origin, destination] of POPULAR_ROUTES) {
    const dates = getNextNDates(7); // pre-warm the next week
    for (const date of dates) {
      await getCached(
        `flights:${origin}:${destination}:${date}`,
        CACHE_TTL.flightAvailability,
        () => searchFlightsAPI(origin, destination, date)
      );
    }
  }
}

This trades a predictable, controlled amount of background API usage for consistently fast responses on your highest-traffic searches — instead of your busiest routes constantly hitting cold caches during peak hours.

Putting It Together: A Realistic Layered Setup

A production travel app caching layer usually ends up looking like this:

CDN edge cache — static/near-static reference data (airports, hotel descriptions)
Redis with tiered TTLs — search results, availability, classified by volatility
Stale-while-revalidate — on top of Redis for search screens, to keep perceived latency low
Lock-based stampede protection — around any high-traffic cache key
Live re-validation — mandatory before booking confirmation, no exceptions
Scheduled pre-warming — for known high-traffic routes/dates

None of these layers is exotic on its own — the skill is knowing which layer to apply to which type of data, and being disciplined about the one hard rule: cache for browsing, never for the final commit.

Closing Thought

The instinct when API costs or latency become a problem is often "cache more." For travel apps specifically, the better instinct is "cache more precisely." Match your caching strategy to how volatile the underlying data actually is, keep the booking path honest with live data, and protect your cache layer itself from stampedes during traffic spikes. Get those three things right and you can cut API calls dramatically without ever showing a user a price you can't actually honor.