Hey,

I’m a web developer – building UIs with React, TypeScript, Tailwind, and modern web tools. A few months ago, I decided to step into Machine Learning.
No prior ML background. Just curiosity and basic Python knowledge.I started Andrew Ng’s Machine Learning Specialization and created my own study plan. Here’s what the first 30 days looked like — the concepts that clicked, the mistakes I made, and what surprised me most.

Week 1: Building the Math Foundation
I started with prerequisites because they’re essential:

• Linear Algebra (vectors, matrices, eigenvalues)
• Calculus (derivatives, partial derivatives, gradients)
• Probability & Statistics

Concept: Why Gradients Matter
Gradient descent is the engine behind almost all modern ML.
Imagine you’re trying to reach the bottom of a valley in the dark. The gradient tells you the direction and steepness of the slope. You take a small step downhill.

(w = w - learning_rate * gradient)

Repeat until you reach the minimum.
This simple idea powers neural networks, linear regression, and more.

Weeks 2–3: Supervised Learning (The Real Fun Begins)
I dove into regression and classification:

• Linear & multiple linear regression
• Logistic regression for classification
• Cost functions, gradient descent, regularization, feature scaling, softmax

I built small projects in Colab:

• House price predictor (linear regression)
• Spam email classifier (logistic regression)

Concept: Regularization
Regularization is like putting guardrails on your model. Without it, the model can memorize noise in the training data (overfitting). With L2 regularization, we penalize large weights, helping the model generalize better.

Weeks 4–5: Neural Networks & Tree Ensembles
This is where things got exciting:

• Built my first neural networks in TensorFlow (forward propagation + backpropagation)
• Learned decision trees, Random Forests, and XGBoost

Concept: Backpropagation
Forward propagation makes a prediction.
Backpropagation figures out why the prediction was wrong and updates every weight accordingly using the chain rule. It’s like tracing a bug through a chain of React components — but for thousands of parameters.

What Surprised Me Most

1. The math finally made sense when I saw it used in real models.
2. Building small projects > passive watching.
3. ML and web development are a powerful combination — I can already imagine turning these models into real web features.

What’s Next?
I’m continuing the plan:

• More neural network practice
• Full mini-projects
• Course 3 (Unsupervised learning)

I’ll be sharing regular updates here — code, lessons, and notebooks. If you’re also learning ML as a web developer, drop a comment. I’d love to hear your journey too!

The Problem

You are processing some data through background job. But before the processing is done, another request had been made to read the related data.

In this case you are either providing a historic data or serving wrong information.

Solution

Holding the request until the job is executed, could be the simplest solution.
I am not saying it is the only solution, but the simplest one.

Some Scenarios

Lets discuss about some possible scenarios.

Booking Job

When a user request to book a resource between two specifics dates. Let’s assume that it is done by a job. So it might take some time in production load.
In the meantime if another request is asking for that specific users booking data.

File Importing Job

User uploads a file like CSV or XML, you have accepted the file but it also needs processing, which should be done in by a job.
If the user ask for the status of the CSV resource in another request.

The Package

aihimel/laravel-waiting-request is a small Laravel package that solves exactly this — it lets one request park until another piece of work (a job, a sync, a long-running controller action) signals that the resource is ready to read.

Install

composer require aihimel/laravel-waiting-request

Optionally publish the config:

php artisan vendor:publish --tag="waiting-request-config"

How it works

The package exposes a tiny API around four ideas: block, wait, check, resolve. Under the hood it is backed by your Laravel cache — no extra infrastructure, no queue plumbing.

A blocker is identified by a class path and a resource id. That pair becomes a unique cache key, so blockers are per-resource (booking 42 does not interfere with booking 43).

use AihimelLaravelWaitingRequestFacadesLWRequest;

// 1. Block — call this where the background work *starts*
LWRequest::addBlocker(Booking::class, $booking->id);

// 2. Wait — call this in the request that wants to read the resource
$resolved = LWRequest::whenResolved(Booking::class, $booking->id);

if ($resolved) {
    return BookingResource::make($booking->fresh());
}

return response()->json(['message' => 'Still processing, try again'], 202);

// 3. Resolve — call this when the background work finishes
LWRequest::resolveBlocker(Booking::class, $booking->id);

You can also peek without waiting:

if (LWRequest::isBlocked(Booking::class, $booking->id)) {
    // resource is mid-flight
}

Applying it to the scenarios

Booking job. The controller that accepts the booking calls addBlocker(Booking::class, $id) and dispatches the job. The job calls resolveBlocker(...) in its handle() (or in a finally block). Any reader that hits GET /bookings/{id} in the meantime calls whenResolved(...) first and only reads the model once the writer is done.

File importing job. Same shape: addBlocker(Import::class, $import->id) when the upload is accepted, resolveBlocker(...) when the parser finishes (success or failure — both should release). The status endpoint calls whenResolved(...) so the client gets a settled answer instead of a half-imported snapshot.

Sensible defaults you can tune

Every knob lives in config/waiting-request.php and is overridable via env:

addBlocker() takes an optional third argument so you can bump the TTL per call when you know a particular job runs longer:

LWRequest::addBlocker(Import::class, $import->id, 120); // 2 minutes

Why the blocker has a lifetime

If a job crashes before calling resolveBlocker(), you do not want readers to wait forever. From v2.x every blocker carries a Unix expiry timestamp. The next isBlocked() / whenResolved() call after that timestamp will:

1. Forget the cache entry, and
2. Emit Log::warning('Waiting-request blocker expired without being resolved', [...])

So even if your job dies, traffic recovers on its own and you get a log line telling you it happened.

Do’s and Don’ts

Do

• Do release the blocker in finally. Wrap your job body so a thrown exception still hits resolveBlocker(). Auto-expiry is a backstop, not a happy path.
• Do set max_blocking_time to comfortably exceed your worst-case job duration. If your import averages 8s and worst-cases at 25s, a 10s default will auto-release while the job is still running — defeating the lock.
• Do tune timeout to match your UX budget. If a client is willing to wait 2s for a synchronous response, set timeout=2; do not let whenResolved() hold an HTTP worker for 30s.
• Do flush the cache when upgrading from 1.x to 2.x. Pre-upgrade values stored as true will be read as 1, treated as already-expired, and produce a one-time burst of warning logs.
• Do treat a false return from whenResolved() as “still pending”. Respond with 202 Accepted (or similar) and let the client poll — do not pretend the data is ready.

Don’t

• Don’t put isBlocked() on a hot, read-only path you expect to be side-effect-free. It evicts expired entries and writes a log line. That is intentional, but worth knowing.
• Don’t use it as a distributed mutex for writes. This package is for readers waiting on writers on a best-effort basis. If two writers race, Cache::add() will reject the second addBlocker() (it returns false), but the package does not give you queueing, fairness, or strict mutual exclusion.
• Don’t share a single blocker across unrelated resources. Key it by the real resource (Booking::class + $id), not by something coarse like the user id, or you will block requests that have nothing to do with each other.
• Don’t forget the cache driver matters. array or file drivers will not work across processes. In production, use redis / memcached so the worker that resolves the blocker and the web process that is waiting actually share the same cache.
• Don’t lean on whenResolved() from a queue worker. Polling inside a worker burns a worker slot. Workers should resolve blockers, not wait on them.

That’s the whole package — a couple of facade calls, a cache key per resource, and a sane expiry so nothing wedges. If you’ve ever shipped a ?retry=true hack or a sleep-and-pray in a controller, this is the cleaner version of that.

Source & issues: github.com/aihimel/laravel-waiting-request

I wasted an entire afternoon wondering why Google Search Console kept showing zero rich results for my React app. The breadcrumbs looked perfect in the browser. Users could see them. But Google? Completely blind. The problem wasn’t my breadcrumb component it was that I’d never told Google what those breadcrumbs actually were. Structured data. Four lines of JSON-LD. That was it. Here’s everything I learned, so you don’t lose the same afternoon.

Why React Breadcrumbs Are Invisible to Google

React apps render in the browser. Google’s crawler is getting better at parsing JavaScript, but structured data embedded in client-rendered markup is still unreliable for rich results. The gold standard for breadcrumb rich results in Google Search is JSON-LD schema markup injected into <head> not your visible DOM breadcrumb trail.

The two things are completely separate:

• Your breadcrumb UI component what users see
• Breadcrumb Schema markup what search engines read

Most tutorials show you how to build the UI. Almost none explain the schema side. That’s why your breadcrumbs look fine to you but don’t show up as rich results in Google.

Here’s what a valid BreadcrumbList schema looks like, per Schema.org:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://example.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "My Article",
      "item": "https://example.com/blog/my-article"
    }
  ]
}

Your job is to get exactly this into a <script type="application/ld+json"> tag in <head> on every page that has breadcrumbs.

The Manual Approach: A Custom React Hook

If you’re not using any SEO library, here’s a clean, copy-paste hook that builds and injects breadcrumb schema based on your current route.

// hooks/useBreadcrumbSchema.js
import { useEffect } from "react";

export function useBreadcrumbSchema(crumbs) {
  useEffect(() => {
    const schema = {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      itemListElement: crumbs.map((crumb, index) => ({
        "@type": "ListItem",
        position: index + 1,
        name: crumb.label,
        item: crumb.url,
      })),
    };

    const script = document.createElement("script");
    script.type = "application/ld+json";
    script.id = "breadcrumb-schema";
    script.textContent = JSON.stringify(schema);

    // Remove any existing breadcrumb schema before inserting
    document.getElementById("breadcrumb-schema")?.remove();
    document.head.appendChild(script);

    return () => {
      document.getElementById("breadcrumb-schema")?.remove();
    };
  }, [crumbs]);
}

Then in your page component:

// pages/BlogPost.jsx
import { useBreadcrumbSchema } from "../hooks/useBreadcrumbSchema";

export default function BlogPost({ post }) {
  useBreadcrumbSchema([
    { label: "Home", url: "https://example.com" },
    { label: "Blog", url: "https://example.com/blog" },
    { label: post.title, url: `https://example.com/blog/${post.slug}` },
  ]);

  return <article>{/* your content */}</article>;
}

Result: Every time the component mounts, the correct JSON-LD block is injected into <head> and cleaned up on unmount. Paste it into Google’s Rich Results Test and you’ll see a green checkmark.

One caveat: if you’re using SSR (Next.js, Remix, etc.), this useEffect approach only runs client-side. For SSR, you need to render the script tag server-side which brings us to the next section.

The SSR Problem: Getting Schema Into <head> at Build Time

With Next.js, you can’t rely on useEffect for schema that needs to be in the initial HTML response. The fix is rendering a <script> tag directly in your component using next/head or the App Router’s <Head>:

// app/blog/[slug]/page.jsx (Next.js App Router)
import Head from "next/head";

function buildBreadcrumbSchema(crumbs) {
  return {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    itemListElement: crumbs.map((crumb, i) => ({
      "@type": "ListItem",
      position: i + 1,
      name: crumb.label,
      item: crumb.url,
    })),
  };
}

export default function BlogPost({ params }) {
  const crumbs = [
    { label: "Home", url: "https://example.com" },
    { label: "Blog", url: "https://example.com/blog" },
    { label: "My Post", url: `https://example.com/blog/${params.slug}` },
  ];

  const schema = buildBreadcrumbSchema(crumbs);

  return (
    <>
      <Head>
        <script
          type="application/ld+json"
          dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
        />
      </Head>
      <article>{/* your content */}</article>
    </>
  );
}

Now the schema is part of the server-rendered HTML Google sees it immediately, no JavaScript execution required.

Using a Library: When Manual Gets Tedious

The manual approach is fine for one or two page types. But if your app has ten different page templates (product pages, category pages, blog posts, docs), you’ll end up copy-pasting and slightly mangling that schema builder everywhere. That’s where a dedicated library helps.

I tried a few options and ended up using @power-seo because it handles breadcrumb schema, OpenGraph, and canonical tags from a single config object which matched how I was already thinking about per-page SEO.

npm install @power-seo

import { SEO } from "@power-seo";

export default function BlogPost({ post }) {
  return (
    <>
      <SEO
        breadcrumbs={[
          { label: "Home", url: "https://example.com" },
          { label: "Blog", url: "https://example.com/blog" },
          { label: post.title, url: `https://example.com/blog/${post.slug}` },
        ]}
        title={post.title}
        canonical={`https://example.com/blog/${post.slug}`}
      />
      <article>{/* your content */}</article>
    </>
  );
}

It generates the same JSON-LD output as the manual approach no magic, just less repetition. Whether that’s worth a dependency is your call. For small projects, the hook above is plenty.

What I Learned

• Your visible breadcrumb UI and your breadcrumb schema are two separate things. One is for users, one is for search engines. Both need to exist.
• useEffect-injected schema works for CSR apps, but for SSR/SSG (Next.js, Remix), render the <script> tag server-side inside <head> to guarantee it’s in the initial HTML.
• Always validate with Google’s Rich Results Test (search.google.com/test/rich-results) before assuming it works. It’ll show you exactly what schema Google can parse.
• Keep your schema in sync with your actual URLs. Stale or mismatched item values in your schema are a silent SEO killer Google will ignore the breadcrumb entirely if the URLs don’t resolve.

If you want to see how the full implementation looks in a real Next.js blog (including dynamic route handling), here’s a detailed walkthrough: https://ccbd.dev/blog/how-to-implement-breadcrumb-schema-in-react-using-power-seo

What’s your setup?

Are you handling structured data manually, using a library, or just skipping it entirely and hoping for the best? I’m curious how other React devs are solving this especially on large apps with lots of page templates. Drop your approach in the comments. If you’ve found a cleaner pattern than what I’ve shown here, I genuinely want to know.

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

Planning a trip used to mean bouncing between five browser tabs — one for flights, one for hotels, one for itineraries, one for Reddit threads, and one you forgot you opened. I wanted to collapse that into a single conversation.

Gemma Travel Assistant is an AI-powered chat app that helps you plan trips from scratch. Tell it your budget, your vibe, your dates. Ask follow-up questions. Upload a photo of somewhere you saw on Instagram and ask “where is this, and what should I do there?” It remembers everything you said earlier in the conversation and uses it to give you better answers.

What makes it feel different from a plain chatbot:

• It doesn’t just write paragraphs. When Gemma recommends hotels or destinations, the app parses those recommendations out of the response and renders them as visual cards — name, location, type badge (hotel / destination / restaurant), star rating, price range. You can scan five options in three seconds instead of reading five bullet points.

• Responses stream token by token. You start reading the answer while Gemma is still writing it. For a full 5-day itinerary that can be 600+ words, this makes the experience feel instant instead of frozen.

• It understands images natively. Drop in a photo — a landscape, a hotel lobby, a plate of food — and the model uses it as context. No extra vision pipeline, no OCR. Gemma 4 handles it directly.

Demo

Example conversation:

You: Plan a 5-day trip to Kyoto in October, budget around $1500, I love temples and local food

Gemma: Here’s a day-by-day itinerary for Kyoto in October — peak foliage season, so I’ve planned around the best viewing spots…
(streams in, then suggestion cards appear below for ryokans and restaurants)

You: (uploads a photo of a bamboo forest)

Gemma: That’s Arashiyama Bamboo Grove in western Kyoto. It’s already on day 3 of your itinerary — here are the best times to visit to beat the crowds…

GitHub: https://github.com/mushahidmehdi/gemma-travel-assistant

Code

Stack:
| Layer | Choice |
|—|—|
| Framework | Next.js 16 (App Router) |
| Model | Gemma 4 31B Dense via OpenRouter |
| Styling | Tailwind CSS |
| Markdown | ReactMarkdown |
| Icons | Lucide React |

Project structure:

src/
├── app/
│   ├── api/chat/route.ts   # Streaming SSE proxy → OpenRouter
│   ├── layout.tsx
│   └── page.tsx            # Centered card layout
└── components/
    ├── ChatInterface.tsx   # Input, image upload, message list
    ├── ChatMessage.tsx     # Bubble renderer + suggestion parser
    └── SuggestionCard.tsx  # Hotel / destination / restaurant cards

How I Used Gemma 4

Choosing the model

I went with Gemma 4 31B Dense (google/gemma-4-31b-it). Here’s why that specific model, not the others:

The E2B / E4B models are designed for edge and mobile — brilliant for offline use, but I needed server-grade reasoning quality for multi-day itineraries with budget constraints, visa tips, and local context. A 2B model can hallucinate confidently about things it doesn’t know well.

The 26B MoE model is optimized for throughput. For a travel assistant where a single user sends a message and waits for the reply, throughput wasn’t the bottleneck. Quality and coherence over a long conversation were.

The 31B Dense hits the right balance: strong enough to produce well-structured, accurate travel advice, consistent enough to reliably follow formatting instructions (more on that below), and available on OpenRouter’s free tier so anyone can clone the repo and run it without a credit card.

The 128K context window was the other deciding factor. Planning a real trip is a long conversation. By the time you’ve discussed your budget, chosen a region, rejected two hotel options, added a day trip, and asked about visa requirements, you’ve accumulated thousands of tokens of context. Smaller context windows start dropping earlier constraints. With 128K, nothing gets forgotten.

Streaming the response

The API route doesn’t buffer — it pipes OpenRouter’s SSE stream directly to the browser:

// src/app/api/chat/route.ts
const stream = new ReadableStream({
  async start(controller) {
    const reader = response.body!.getReader();
    const decoder = new TextDecoder();

    while (true) {
      const { done, value } = await reader.read();
      if (done) break;

      const chunk = decoder.decode(value);
      const lines = chunk.split('n').filter(line => line.startsWith('data: '));

      for (const line of lines) {
        const data = line.slice(6);
        if (data === '[DONE]') { controller.close(); return; }
        try {
          const parsed = JSON.parse(data);
          const content = parsed.choices?.[0]?.delta?.content;
          if (content) controller.enqueue(new TextEncoder().encode(content));
        } catch { /* skip malformed chunks */ }
      }
    }
    controller.close();
  },
});

return new Response(stream, {
  headers: { 'Content-Type': 'text/plain; charset=utf-8' },
});

On the client, ChatInterface reads the stream chunk by chunk and appends to the last message in state, so React re-renders progressively as tokens arrive.

Structured output via prompting

I didn’t use a formal structured output API. Instead, the system prompt tells Gemma to append a fenced suggestions block at the end of any response that involves specific recommendations:

When suggesting places, format your hotel/destination/restaurant recommendations
as a JSON block at the end of your response:

suggestions
[{
“name”: “Nishiyama Onsen Keiunkan”,
“location”: “Yamanashi, Japan”,
“type”: “hotel”,
“rating”: 4.9,
“price”: “$$$”,
“description”: “The world’s oldest hotel, operating since 705 AD…”
}]

typescript

ChatMessage then does two things: strips that block from the visible text (so it doesn’t appear as raw JSON in the bubble), and passes the parsed array to SuggestionCard components:

function parseSuggestions(content: string) {
  const match = content.match(/```
{% endraw %}
suggestionsn([sS]*?)
{% raw %}
```/);
  if (!match) return { text: content, suggestions: [] };

  const text = content.replace(/```
{% endraw %}
suggestionsn[sS]*?
{% raw %}
```/, '').trim();
  try {
    return { text, suggestions: JSON.parse(match[1]) };
  } catch {
    return { text: content, suggestions: [] }; // graceful fallback
  }
}

If Gemma omits the block — for a conversational reply like “Great, let’s add a day trip!” — the component falls through cleanly and just shows the text bubble. No crashes, no empty card rows.

Multimodal input

Image uploads are encoded as base64 data URLs and injected into the last user message as an image_url content block — the format OpenRouter and Gemma 4 expect:

if (msg.role === 'user' && image && isLastMessage) {
  return {
    role: 'user',
    content: [
      { type: 'text', text: msg.content },
      { type: 'image_url', image_url: { url: image } }, // base64 data URL
    ],
  };
}

Gemma 4’s native vision understands the image without any preprocessing on my end — no external OCR, no separate vision model call. The model sees both the image and the conversation history and responds in context.

Building this made me appreciate how much the context window size and multimodal capability change what’s actually possible in a single conversation. A travel assistant that forgets what you said three messages ago, or that can’t look at a photo you found, is just a fancier search box. Gemma 4 31B makes it feel like talking to someone who’s actually paying attention.

Microsoft tried to kill the printer driver. 90% of US healthcare said no.

In late 2025, Microsoft put a line on the Windows Roadmap that should have read as routine. Starting January 2026, Windows Update would stop shipping legacy V3 and V4 printer drivers. Modern Print Platform only. Goodbye to a decade of brittle vendor blobs.

In February 2026 they quietly took it back. The line vanished from the roadmap. The official statement told users no action applies. Existing printers will keep working. The deprecation, for now, sits on hold.

Microsoft holds more market power than almost any company in history. They tried to retire a category of driver that Microsoft itself deprecated back in September 2023. They could not actually pull it off. The reason sits in every hospital in the United States, and it makes a noise like a 1990s modem.

TL;DR

1. The headline that almost happened

The original Microsoft plan looked clean. V3 and V4 driver models carried known security and stability problems. Modern Print Platform, the IPP based replacement, outperforms them in almost every measurable way. Microsoft already deprecated the old drivers two and a half years ago. The January 2026 update would have completed the cleanup.

That plan sits in the archive now. Tom’s Hardware and Windows Central covered the original announcement. The retraction came after Microsoft “received feedback.” The polite version of “received feedback” reads as follows: some quite large customers told Microsoft, in writing, that breaking the printer pipeline would break the hospital pipeline, and that the hospital pipeline runs on fax.

2. The fax number you cannot believe

Here is the statistic that broke my brain when I first read it. Roughly 70 percent of healthcare communication in the United States still moves over fax. When you include EHR linked faxing, where an electronic health record system pretends to be a fax machine in order to talk to the rest of the industry, the number climbs to about 90 percent.

Ninety percent. Of the most regulated, most digitized, most money-flooded industry in the developed world. Running on a protocol that predates the personal computer.

   The 2026 healthcare comms diagram

  ┌──────────────┐         FAX           ┌──────────────┐
  │   Hospital A │  ─────────────────▶   │   Clinic B   │
  │   (modern    │                       │   (modern    │
  │    EHR)      │                       │    EHR)      │
  └──────────────┘                       └──────────────┘
        │                                       │
        ▼                                       ▼
   Pretends to be                          Pretends to be
   a fax machine                           a fax machine
        │                                       │
        ▼                                       ▼
  ╔═════════════════════════════════════════════════════╗
  ║   90% of the actual traffic goes over fax anyway    ║
  ╚═════════════════════════════════════════════════════╝

That diagram explains what Microsoft hit when they tried to ship the driver change. The driver path covers more than home offices. The driver path runs through compliance pipelines that no single engineering team owns. Break the driver layer in January, and somebody’s referral cannot reach somebody else’s prior authorization in February. That outcome does not fit a “we will respond to feedback” narrative. That outcome makes a 60 Minutes segment.

3. The other infrastructure that refuses to die

Fax counts as the most visible example. Not the only one. The pattern shows up everywhere stable infrastructure built up decades of edge cases. IBM has said for years, in slightly louder volumes each year, that COBOL still runs about 95 percent of ATM transactions and more than 40 percent of online banking. The COBOL workforce is aging out. The replacements never arrived. The systems keep running.

Same pattern with:

We tell each other we live in a world of rapid change. The world actually sits on one of the most stable substrates the species has ever built. The application layer churns. The substrate hardly moves at all.

4. The lesson for software you ship today

You will not build fax machines. You will, almost certainly, write code that outlives your current job, your current company, and possibly your current career. That outcome sits at the heart of the COBOL story that nobody puts on a slide. The COBOL devs in 1985 did not know their code would still run in 2026. They just shipped.

The code you wrote last week might still serve as a production database adapter in 2040. The defaults you picked stand a chance of becoming invariants for some future maintainer who has never met you. Five practical rules that pay back over the decade-scale arc of code:

Rule 1: Comment the boundary, not the line

Your future maintainer can read your code. They cannot read your decision tree. Write down why a particular flag exists, why a particular workaround sits where it does, why a particular value lives as a constant. Skip the obvious. Document the negotiations.

# bad
TIMEOUT = 47

# good
# Set to 47 seconds because the partner auth gateway has a hard 50s limit
# and we observed 1-2s of jitter from our load balancer in the May 2023
# postmortem. Do not raise without coordinating with the integrations team.
TIMEOUT = 47

The bad comment captures what the code already says. The good comment captures the negotiation that produced the number, which is the part that erases first.

Rule 2: Pick formats that read in plain text

JSON, CSV, plain SQL, basic English logs. The dependency on a binary format with proprietary tooling bites archaeologists hardest. If somebody can cat the file in 2046 and start guessing what it does, you have done them a favor that pays back forever.

The fax format is plain enough that a forensic analyst can read it with the right hardware. COBOL source is plain enough that a junior dev with a manual can read it. The systems that died fastest in the 1990s and 2000s were the ones that depended on a binary tool that the vendor stopped supporting. Choose against that future.

Rule 3: Write the migration script you wish someone had written for you

Every meaningful schema change should ship with the SQL or code that undoes it, or that walks the data from the old shape to the new one. Future you, or future someone, will thank you.

-- Forward migration
ALTER TABLE users ADD COLUMN preferred_locale VARCHAR(10) DEFAULT 'en-US';
UPDATE users SET preferred_locale = 'en-GB'
  WHERE country_code IN ('GB', 'IE', 'AU', 'NZ');

-- Down migration (commit this in the same file)
ALTER TABLE users DROP COLUMN preferred_locale;

Tools like Alembic, Flyway, Liquibase, and Sequelize migrations enforce this discipline. If your team is doing migrations as ad-hoc DBAs running scripts in pgAdmin, you are storing technical debt that compounds at the rate of every release.

Rule 4: Version your wire formats from day one

The number one source of unkillable legacy infrastructure is a public protocol that grew without a version field. The 1843 fax protocol gained version negotiation only when CCITT standardized it. The internet has 30 years of bolt-on versioning because TCP/IP shipped without it. Avoid being the contributor of the next one.

// good API response, version everywhere
{
  "version": "2026-05-01",
  "data": { "..." }
}

Use date-based versioning, header-based versioning, or URL-based versioning. Pick one. Use it consistently. When you need to make a breaking change in five years, the version field is the only thing that lets you do it without breaking every client at once.

Rule 5: Write a CHANGELOG that survives the company

CHANGELOG.md, in the root of every repo you own. One entry per release. Date, version, and a sentence per change. Not generated. Written by a human. The future maintainer reads this before they read your code.

## [2026-05-12] - 2.4.1
- Fixed billing rounding bug where orders with >100 line items
  rounded the tax down by 1 cent. See incident 2026-05-09.
- Raised the partner gateway timeout from 30s to 47s. Coordinated with
  the integrations team. Do not raise further.

The CHANGELOG is the only document that gets read in 2040. Make it count.

5. A short tour of the substrate you depend on right now

If you think your stack is modern, the following table is for you. The right column is the year the underlying protocol or format reached its current dominant form. Every one of these things runs in the path of the request that loaded this article.

The newest thing on that list is H.264, and it is 23 years old. Everything else has been there longer than most of the people reading this article have been alive. The “modern stack” is a thin veneer of frameworks over a substrate that predates the personal computer in most cases.

This is not bad news. It is the most stable substrate any creative discipline has ever had to work on. Painters change pigments every century. Architects change materials every generation. Software engineers work on a foundation that has been mostly stable for 40 years. That foundation is what makes everything we build possible.

6. The honest take

A tempting story sits here that goes “legacy is bad and we should kill it.” That story misses the picture. The legacy systems stayed around because they work. A hundred million transactions a day stress-tested them, in front of regulators who would happily fine the carrier that broke them. The new systems will, eventually, earn the same proof. They have not yet.

The reasonable position lands at humility. We do not count as the first generation to write important software. We will not count as the last. The substrate predates us. The substrate will probably outlast us.

In a strange way, that picture reassures rather than worries. Microsoft cannot delete the printer driver. The fax machine still rings in your hospital. The work matters.

The bottom line

A driver deprecation that should have been routine got walked back because the substrate it sits on is older, weirder, and more important than the people deprecating it remembered. Healthcare runs on fax. Banking runs on COBOL. Your job, whatever you ship next, is going to land in someone’s legacy/ directory eventually. Write it like the next person matters.

Question for the comments: what is the oldest piece of infrastructure your job still depends on, and how surprised would your CTO be to learn it is in the critical path?

GDS K S · thegdsks.com · follow on X @thegdsks

The most modern thing in your stack is the part that is about to be legacy.

If you’ve spent any time around telecom billing systems, you know they’re not your typical CRUD app. You’ve got prepaid balances, real-time charging, usage events flying in every second, and downstream systems that need to know about things right now not in 30 seconds. So when you’re wiring up integrations, the question of “do we poll or do we listen?” comes up fast.

how REST APIs and webhooks actually play out in this context, and where each one earns its place.

The Core Difference (Without the Textbook Version)

REST APIs are pull-based. Your system asks: “Hey, what’s the current balance for subscriber X?” and the billing system replies. You’re in control of when data moves.

Webhooks flip that. The billing system says: “Subscriber X just crossed their data threshold here’s the event payload, do something with it.” You register a URL, and the billing system pushes to you when something happens.

Neither is universally better. They solve different problems, and in telecom billing, you often end up using both.

Where REST APIs Work Well

Account and balance queries. When a customer calls in or opens the self-care portal, you need their current balance, active plan, and usage summary on demand. That’s a perfect REST use case you fire a request, you get a response, you render it. Platforms like Optiva (formerly Sigma Systems) and Comarch expose rich REST APIs for exactly this their BSS layers are designed for synchronous, request-response interactions when an operator needs to read or update subscriber data.

Provisioning and plan changes. When a customer upgrades their plan, you need to write that change to the billing system, confirm it succeeded, and then maybe update a few other systems. REST is clean here because the flow is sequential and you need confirmation before you move on.

Reporting and reconciliation. Finance teams running end-of-day or end-of-month reconciliation are querying aggregated data at their own cadence. REST is the right tool no need to react to events, just pull what you need when you need it.

Alepo Technologies, which focuses heavily on prepaid and convergent charging, has built a lot of their integration surface around REST for these provisioning and management workflows. It makes sense operators need predictable, auditable writes into the billing system, not fire-and-forget events.

Where Webhooks Actually Earn Their Keep

Real-time telecom billing is where REST starts to show its limits.

Think about a prepaid subscriber whose balance hits zero mid-call. Or a data session that needs to be throttled when someone blows through their monthly cap. Or a fraud detection system that needs to act the moment a suspicious usage pattern appears. Polling for these events is expensive, laggy, and just architecturally wrong.

CSG(which handles billing for some of the largest carriers globally) and Qvantel (known for their cloud-native BSS stack) both lean into event-driven architectures for this reason. When your billing platform can push usage events, threshold crossings, or payment failures as webhooks, downstream systems can react in near real-time without hammering the billing system with constant polling.

A few concrete scenarios where webhooks shine in telecom:

• Low balance notifications:- push to notification service the moment a subscriber drops below a threshold, instead of polling subscriber balances every few minutes
• Session events:- data session start/stop pushed to analytics or policy enforcement
• Payment events:- successful top-up triggers immediate service restoration without a polling loop
• Fraud triggers:- anomalous usage event fires immediately to a fraud management system

TelcoEdge Inc. has made event-driven billing a core part of their pitch, particularly for operators moving toward real-time charging in 5G environments where latency in billing events can directly affect service delivery.

The Honest Trade-offs

Here’s where it gets real. Webhooks sound great until you have to operate them at scale.

Reliability is your problem now. With REST, if the call fails, you retry it. With webhooks, if your endpoint is down, you might miss events. You need dead letter queues, retry logic with exponential backoff, and idempotency on the receiving end. Billing events especially you cannot process a “payment received” webhook twice.

Ordering isn’t guaranteed. Events can arrive out of order. A “balance depleted” event and a “top-up received” event for the same subscriber might arrive in the wrong sequence depending on network conditions and load. Your consuming system has to handle that gracefully.

Security surface is different. With REST you control who calls you. With webhooks, someone’s pushing data to a URL you’ve exposed you need signature verification, TLS, and ideally IP allowlisting. Most mature billing platforms handle this well; Comarch’s telecom billing stack, for example, includes webhook signature mechanisms, but you still have to implement verification on your end.

Debugging is harder. A failed REST call gives you an immediate 4xx or 5xx and a stack trace. A missed webhook event might not surface until a customer complains their service wasn’t restored after topping up.

REST has its own pain points too polling overhead, rate limits, and the tendency for systems to build up nasty polling loops “just to be safe.” Plenty of telecom backends have been brought to their knees by clients polling every 5 seconds for account changes.

What Hybrid Actually Looks Like in Practice

Most real telecom billing integrations end up using both, and that’s not a cop-out answer it’s just how the problem decomposes.
A typical pattern: REST for writes (provisioning, plan changes, payment posts) and synchronous reads (account details, balance checks on demand), webhooks for async events (threshold alerts, session events, fraud signals, payment confirmations).

Qvantel’s cloud-native BSS architecture explicitly supports this their platform exposes REST for management operations and publishes events via webhooks or Kafka topics for real-time operational flows. That kind of separation makes the integration surface much cleaner.

The trend in 5G and cloud-native BSS is pushing more toward event-driven, but REST isn’t going anywhere. It’s still the right tool for structured, transactional interactions where you need a confirmation before proceeding.

Practical Advice If You’re Evaluating This

If you’re currently building or evaluating an integration with a telecom billing system:

• Map your latency requirements first. If an event needs to trigger an action within seconds, you need webhooks or a message bus. If 10-30 seconds is acceptable, polling might be fine.
• Check what the platform actually supports, not just what’s in the docs. A lot of BSS platforms claim webhook support but have gaps event coverage, retry policies, payload schemas. Ask specifically which events are supported.
• Plan for webhook failure from day one. Don’t build assuming events will always arrive. Have a reconciliation job that can catch missed events via REST polling as a fallback.
• Don’t over-engineer early. If you’re integrating with a relatively small MVNO or a lower-volume billing scenario, REST polling with a reasonable interval might genuinely be fine. Not every integration needs a full event-driven architecture.
• Platforms like Alepo, Optiva, and Comarch all have integration teams that can walk you through what’s actually available vs. what’s on the roadmap worth those conversations before you commit to an architecture.

The REST vs. webhooks question in telecom billing isn’t really a competition. It’s about understanding what each mechanism is good at and matching it to the problem. Synchronous, transactional, confirmed operations belong on REST. Asynchronous, time-sensitive, event-driven reactions belong on webhooks. Build both into your integration design and you’ll be in much better shape than teams that went all-in on one approach and spent months retrofitting the other.