DEV Community: Islam Hafez

POST /search Is a Lie. HTTP Finally Admits It.

Islam Hafez — Wed, 08 Jul 2026 22:47:27 +0000

For 30 years, every search API on the internet has been telling the protocol one thing and doing another. RFC 10008 just ended that.

Somewhere in your codebase right now, there is a route called POST /search.

It works. It has always worked. And every developer who wrote it knew, at some level, that it was wrong — that using POST for a read-only operation was a small, quiet lie to the protocol. They wrote it anyway because HTTP left them no choice. The only verb that could carry a body was POST, and POST is defined to mean "this operation might change something."

For three decades, every search API, every filter endpoint, every analytics query, every reporting tool on the internet made the same compromise. We picked the verb that worked over the verb that was correct, because the correct verb didn't exist.

On June 15, 2026, after eleven years of drafts, the IETF published RFC 10008. The new method is called QUERY. And the first thing to understand about it is that it isn't really adding something new. It's making the protocol honest about what we were already doing.

Why the Lie Happened in the First Place

HTTP has always had a semantics problem for complex reads.

GET is the right verb for reading data. It's safe (no side effects), idempotent (repeat it a hundred times, same result), and cacheable. Proxies can retry it. CDNs can cache it. Clients can prefetch it. Everything about GET is designed around the assumption that reading data is a safe operation that can be done again without consequence.

The problem is the URL. GET has no body. Your entire request — every filter, every parameter, every field — has to fit in the URI. And nobody actually knows what "fit" means, because the size limit isn't defined by HTTP itself. It depends on the browser, the server, every proxy in between, and every CDN in the path. RFC 9110 recommends servers support at least 8,000 octets. Some support less. Some support more. None of them agree.

For simple queries, that's fine. GET /products?category=laptops&sort=price fits anywhere. But modern APIs don't stay simple:

GET /analytics/reports
  ?filters[]=region:US,EU
  &filters[]=date_range:2026-01-01..2026-06-30
  &filters[]=revenue:>10000
  &group_by[]=month,region,product_line
  &having[]=total_revenue:>50000
  &sort=total_revenue:desc
  &fields[]=id,name,revenue,margin,growth_rate
  &page=1&per_page=100

That's not contrived. That's a real analytics query. In a URL. And this is the mild version — Elasticsearch DSL, GraphQL queries, and SQL-style filter trees make this look minimalist.

So teams switched to POST. And POST solved the body-size problem and created a different one: POST is defined to mean "this might have side effects." It is neither safe nor idempotent by default. Caches ignore POST responses. Proxies won't automatically retry a failed POST. Monitoring tools flag POST calls as potentially state-changing. OpenAPI specs describe them under the "mutations" section. Every piece of infrastructure that makes decisions based on HTTP semantics now has the wrong information about what your search endpoint does.

We weren't just working around a limitation. We were telling the protocol a lie, and that lie had real costs.

What QUERY Actually Is

QUERY is a single, precise addition to the HTTP method registry. Four properties, two of which it inherits from GET and two from POST:

From GET: Safe. Idempotent.
From POST: Carries a request body.
New: Explicitly cacheable with a body.

QUERY /products HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json

{
  "filters": {
    "category": "laptops",
    "price": { "min": 500, "max": 2000 },
    "in_stock": true
  },
  "sort": { "field": "price", "direction": "asc" },
  "page": 1,
  "per_page": 50
}

The request body carries the query. The method communicates what the request does. The protocol and the intent finally match.

Servers advertise which body formats they accept via a new Accept-Query response header. The RFC's examples include application/json, application/x-www-form-urlencoded, application/sql, application/jsonpath, and application/xslt+xml. QUERY doesn't care what format the body is — it's format-agnostic by design. A REST API, a GraphQL server, and an Elasticsearch cluster can all speak QUERY using their own body conventions.

The Timeline: 11 Years. 16 Years. Both True.

The idea behind QUERY isn't new. The first draft circulated roughly eleven years ago. It moved through review for over a decade, reached a final draft in November 2025, received IESG approval on November 20, 2025, and was published as RFC 10008 on June 15, 2026.

The last genuinely new HTTP method before this was PATCH, published as RFC 5789 in March 2010. That makes QUERY the first new general-purpose HTTP method in sixteen years.

Both numbers — eleven years to draft, sixteen years since the last new method — are features, not bugs. HTTP underpins the entire web. A change to it gets reviewed against every server, every browser, every proxy, every CDN, every security assumption, every existing implementation that exists on the planet before it becomes a standard. That process is deliberately slow. It's why "new HTTP method" is real news, not framework noise.

The RFC is 24 pages. Read it. It's unusually readable for an IETF document — the problem statement alone is worth your time.

The Author List Tells You Something

RFC 10008 carries three names: Julian Reschke of greenbytes, James M. Snell of Cloudflare, and Mike Bishop of Akamai.

Cloudflare and Akamai, between them, sit in front of a significant portion of the web's traffic. These aren't academic researchers speculating about how CDNs might behave. They are the CDN. Their involvement in writing the spec means the caching behavior — the hardest part to get right — was designed by people who operate the caching infrastructure it will run on.

That matters more than it sounds. Caching a GET response is straightforward: the URL is the cache key. Caching a QUERY response requires including the request body in the cache key, and getting that wrong opens cache poisoning attacks. The spec is precise about this because the people who wrote it will also be the ones whose infrastructure gets poisoned if they got it wrong.

Caching: The Part That Actually Changes Everything

The difference between QUERY and POST /search isn't just semantic cleanliness. It's whether your responses can be cached.

POST responses are not cached by default. Every search request hits your server fresh. For simple APIs, that's fine. For high-traffic search endpoints — a product catalog, a content discovery feed, a real-time analytics dashboard — it means every filter combination, every repeated query, every pagination request goes to the origin. No CDN edge caching. No shared cache hits. Your server takes the full load.

QUERY is explicitly cacheable. A CDN can store the response to a QUERY request and serve it to the next client who sends the same request body to the same URL. For read-heavy APIs, that's not a minor ergonomic improvement. It's a different performance tier.

The catch: the cache key must include the full request body, not just the URL. A cache that keys on the URL alone will serve one user's search results to every user who queries the same endpoint — regardless of what their filter body says. That is a cache poisoning vulnerability, and it requires no bug in the application. It's a misconfigured cache.

This is the part your infrastructure team needs to understand before you ship QUERY anywhere near production.

What the Protocol Now Lets Intermediaries Do

The semantic shift from POST to QUERY isn't just about correctness. It's about what intermediaries — proxies, CDNs, load balancers, API gateways — are permitted to do with your requests.

With POST, intermediaries have to assume the operation might have side effects. They won't cache it. They won't automatically retry a failed request. They won't prefetch it. They treat it like a state change, because that's what the protocol says POST might be.

With QUERY:

Caches can store and reuse responses.
Clients can safely retry a failed QUERY without worrying about double-submission.
Proxies can automatically retry on network failures.
Monitoring tools can correctly classify it as a read operation.
OpenAPI specs can describe it accurately without gymnastics.
Rate limiters can apply read-operation quotas instead of write-operation quotas.

Every layer of the stack that currently makes decisions based on HTTP method semantics gets the right information. That's not a cosmetic improvement. Distributed systems built around HTTP use method semantics to make real decisions about retry behavior, caching, and traffic routing. Giving them accurate semantics means those decisions become correct.

Where It Works Today (Be Specific With Yourself)

Environment	Status — July 2026
Node.js	Native QUERY parsing since early 2024 ✓
OpenAPI 3.2	Full documentation support ✓
curl	Supported — `curl -X QUERY ...` ✓
GraphQL servers	Natural fit for query operations (server-side) ✓
Spring (Java)	PR open, `RequestMethod` enum not yet updated ✗
Ruby on Rails	Discussion stage only ✗
Chrome / Firefox / Safari	Still evaluating; `fetch()` not yet ✗
WAFs (default rulesets)	Not included in method allowlists pre-June 2026 ✗
CDNs (default config)	Varies — verify explicitly before relying on it ✗

Node.js is ready. OpenAPI is ready. Your WAF is probably not.

The browser gap is the most significant constraint for public-facing APIs. Browser JavaScript's fetch() doesn't support QUERY yet as of this writing, which means any API that needs to be called directly from a browser is either stuck on POST-as-fallback or waiting. For server-to-server APIs, internal APIs, and GraphQL backends, the picture is much better.

The Security Side Nobody's Talking About

New HTTP methods are an attack surface before they're a feature. Security infrastructure written before June 2026 doesn't know QUERY exists, which creates gaps that are interesting to both attackers and defenders.

WAF inspection gaps. Web application firewalls typically enforce method allowlists: GET, POST, PUT, DELETE, PATCH. A WAF that doesn't know about QUERY might pass it through without running the injection and XSS detection rules it would run against a POST body carrying the same payload. This isn't a theoretical problem — test it yourself:

# Send the same payload via POST first
curl -X POST https://target.com/api/search \
  -H "Content-Type: application/json" \
  -d '{"q": "test OR 1=1"}' -v

# Then try QUERY
curl -X QUERY https://target.com/api/search \
  -H "Content-Type: application/json" \
  -d '{"q": "test OR 1=1"}' -v

If your WAF blocks the POST but passes the QUERY, you've found a live inspection gap in your own infrastructure. Fix that before you enable QUERY in production.

Cache poisoning. Already covered above — but worth repeating in plain terms. If a cache doesn't include the full request body in its cache key, two different QUERY requests to the same URL will share a cache entry. User A searches for {"category": "laptops"}. User B searches for {"category": "phones"}. If the cache keys on URL alone, User B gets User A's laptop results. Worse: an attacker can deliberately populate the cache with a crafted response that other users will receive.

CORS preflights. QUERY is not a CORS-safelisted method. Any browser JavaScript calling a QUERY endpoint cross-origin will trigger a preflight OPTIONS request — same as PUT or DELETE. The spec got this right on purpose. But your CDN, reverse proxy, and CORS middleware all need to handle that preflight consistently. Don't assume — test the actual path.

CSRF audit. CSRF middleware is typically scoped to state-changing methods. QUERY is safe by spec — but a developer might implement a QUERY endpoint that has an unintended side effect (logging, rate-limit tracking, "last searched" timestamp updates). If your CSRF middleware doesn't cover QUERY because it's "safe," those side effects get a free pass from cross-site requests. Audit any QUERY endpoint with side effects explicitly.

GraphQL Finally Has the Right Verb

GraphQL is the clearest example of how far POST /search misrepresented what APIs were actually doing.

GraphQL query operations — not mutations, not subscriptions, just queries — are already safe, already idempotent, and already read-only by design. They've been executed over POST /graphql for years because GET couldn't carry the complex JSON bodies that GraphQL operations require.

QUERY is the verb GraphQL queries were always supposed to use. The operation is read-only. The method is now QUERY. The semantics match. CDN caching of GraphQL query responses becomes correct-by-default rather than requiring custom cache configurations that fight against POST semantics.

Server-side GraphQL frameworks are among the first candidates to ship QUERY support, and the alignment is clean enough that they should.

The Practical Migration Path

Don't do a hard cutover. The ecosystem isn't ready.

The right approach is additive: keep POST /search running alongside the new QUERY endpoint. Advertise QUERY support via the Accept-Query response header on the POST response. Let clients migrate as their tooling catches up. When QUERY traffic exceeds POST traffic for a given endpoint, deprecate POST. Until then, both coexist.

Before you enable QUERY anywhere that matters, four things need to be explicitly verified:

1. Your framework routes it. Don't assume — check the specific version. Spring doesn't yet. Rails doesn't yet. Express with Node 22+ does.

2. Your WAF inspects the body. Run the comparison test above. If the WAF treats the QUERY body differently from a POST body, that's a problem to fix now, not after you've launched.

3. Your cache includes the body in the key. This is the highest-priority item for any public API. A misconfigured cache is worse than no caching — it serves wrong data to real users.

4. Your CORS and CSRF middleware covers it. Don't rely on inheritance from POST behavior. Explicitly add QUERY to the method list your security middleware handles.

The Honest Summary

Property	GET	POST	QUERY
Safe (no side effects)	Yes	No	Yes
Idempotent	Yes	No	Yes
Cacheable by default	Yes	No	Yes
Carries a request body	No	Yes	Yes
CORS preflight required	No	Depends	Yes
Standard since	1991	1996	June 2026

What This Signals About HTTP Itself

PATCH took sixteen years from proposal to wide adoption. QUERY will probably follow a similar arc. The IETF doesn't ship methods on a quarterly release cycle, and that's exactly why each one matters.

The gap since PATCH was published in March 2010 is sixteen years. In those sixteen years, the web went from REST APIs being novel to REST APIs being infrastructure. The entire time, every search endpoint on the internet was using the wrong verb, and the protocol had no answer.

RFC 10008 is a 24-page document. It will take years to fully propagate through frameworks, WAFs, CDNs, and developer habits. But the vocabulary of HTTP — the shared language every API on the internet speaks — just got one new word. A word that makes it possible, for the first time, to say what POST /search was always trying to say.

RFC 10008 is available in full at rfc-editor.org/info/rfc10008. The IESG approval record and public review comments are on the IETF datatracker at datatracker.ietf.org/doc/rfc10008. All framework and browser support statuses are current as of July 2026.

Cheers!

You Don't Use Linked Lists. But They're Running Half Your Software.

Islam Hafez — Sat, 27 Jun 2026 14:13:23 +0000

The data structure everyone learns for interviews and forgets by Monday — and why that's exactly backwards.

Here's the honest version of what most linked list tutorials skip:

You are almost certainly never going to write a linked list in JavaScript. Not in production. Not in a side project. Your language's built-in array already handles dynamic sizing, and it does it faster than a linked list in most cases, for reasons we'll get into. The interview circuit trained you to implement one on a whiteboard, and that's fine — but it created the wrong mental model. You walked away thinking linked lists are a data structure you might use. They're actually a data structure you need to understand — because they're hiding inside the tools you use every day, and knowing they're there changes how you reason about performance.

Your browser's back/forward navigation? Doubly linked list. Your text editor's undo history? Doubly linked list. The LRU cache inside every high-traffic web server, CDN, and database query optimizer? A doubly linked list fused with a hash map. Redis's LPUSH/RPUSH commands operate on a linked list. The Node.js event queue has linked list characteristics. The Linux kernel's process scheduler uses circular doubly linked lists internally.

They're not a relic. They're infrastructure. You just can't see them because they're one layer below where you usually work.

So let's learn them the right way — starting with the hardware, not the textbook.

Why Memory Layout Is the Whole Story

Before you write a single node, you need to understand the one thing that determines when a linked list wins and when it loses: cache locality.

Your CPU doesn't read from RAM one byte at a time. It's too slow for that — a RAM access takes 200–300 CPU cycles, while a cache hit takes 4. So the CPU plays a prediction game: when you access a memory address, it automatically pulls in the surrounding 64 bytes (a "cache line") on the assumption that you'll need nearby data next. This is called spatial locality, and it's why arrays are fast.

When you store an array of numbers, they sit next to each other in memory. When you loop over them, the CPU loads the first element — and gets the next 15 for free in the same cache line. It's reading ahead before you even ask.

Array in memory:
[ 10 | 20 | 30 | 40 | 50 | 60 ] → contiguous, cache-friendly
  ^                               one cache fetch, all 6 loaded

A linked list destroys this. Each node is a separate heap allocation, scattered wherever the allocator found space. Following a next pointer means jumping to an arbitrary memory address — potentially on a completely different cache line, triggering a new RAM fetch, costing those 200–300 cycles, every single time.

Linked list in memory:
[10 | ptr] ──→ [20 | ptr] ──→ [30 | ptr]
 0x1a04          0x7f82         0x3c11
 (separate allocations, scattered across memory)

In practice, benchmarks consistently show linked list traversal running 10–100x slower than array traversal for large datasets — even though both are O(n) on paper. Big-O notation lies to you about this. It ignores constants, and the constant for "RAM access" is enormous on modern hardware.

This isn't a reason to dismiss linked lists. It's the reason to understand exactly when their advantages outweigh this cost. That answer is more specific than most tutorials admit.

Singly Linked List — The Minimal Form

A singly linked list is a chain of nodes where each node holds data and a pointer to the next node. That's it. No backward travel. No shortcuts.

class Node {
  constructor(value) {
    this.value = value;
    this.next = null;
  }
}

class SinglyLinkedList {
  constructor() {
    this.head = null;
    this.size = 0;
  }

  // O(1) — we know exactly where the head is
  prepend(value) {
    const node = new Node(value);
    node.next = this.head;
    this.head = node;
    this.size++;
  }

  // O(n) — must walk to the end
  append(value) {
    const node = new Node(value);
    if (!this.head) {
      this.head = node;
    } else {
      let current = this.head;
      while (current.next) current = current.next;
      current.next = node;
    }
    this.size++;
  }

  // O(n) — must walk to find it
  delete(value) {
    if (!this.head) return;

    if (this.head.value === value) {
      this.head = this.head.next; // drop the head, O(1)
      this.size--;
      return;
    }

    let current = this.head;
    while (current.next) {
      if (current.next.value === value) {
        current.next = current.next.next; // skip the node, O(1) once found
        this.size--;
        return;
      }
      current = current.next;
    }
  }

  toArray() {
    const result = [];
    let current = this.head;
    while (current) {
      result.push(current.value);
      current = current.next;
    }
    return result;
  }
}

Notice something about delete: finding the node is O(n), but the actual removal is O(1) — you just redirect one pointer. No shifting. No copying. No reorganizing memory. Compare that to an array, where deleting from the middle means shifting every subsequent element one position left — O(n) work even after you found the element.

This is the trade-off in one sentence: linked lists pay for access with their insertion/deletion advantage.

The singly linked list's natural shape is a stack — you push and pop from the head, both O(1), never need to go backward. It also fits a task queue where you only ever consume from one end.

What it genuinely can't do: random access. If you want the 500th element, you walk 500 nodes. There's no formula. This alone disqualifies singly linked lists from most use cases where you're searching or indexing.

Doubly Linked List — Where It Gets Actually Useful

Add a prev pointer to every node and something real changes: you can traverse in both directions, and — critically — you can remove a node in O(1) if you already have a reference to it.

class DNode {
  constructor(value) {
    this.value = value;
    this.next = null;
    this.prev = null;
  }
}

class DoublyLinkedList {
  constructor() {
    this.head = null;
    this.tail = null;  // tail pointer makes append O(1)
    this.size = 0;
  }

  // O(1) — we hold both ends
  prepend(value) {
    const node = new DNode(value);
    if (!this.head) {
      this.head = this.tail = node;
    } else {
      node.next = this.head;
      this.head.prev = node;
      this.head = node;
    }
    this.size++;
  }

  // O(1) — tail pointer, no walking required
  append(value) {
    const node = new DNode(value);
    if (!this.tail) {
      this.head = this.tail = node;
    } else {
      node.prev = this.tail;
      this.tail.next = node;
      this.tail = node;
    }
    this.size++;
  }

  // O(1) — given the node directly, no searching required
  removeNode(node) {
    if (node.prev) node.prev.next = node.next;
    else this.head = node.next; // it was the head

    if (node.next) node.next.prev = node.prev;
    else this.tail = node.prev; // it was the tail

    node.next = node.prev = null;
    this.size--;
  }

  // O(1) — both ends accessible instantly
  removeHead() { if (this.head) this.removeNode(this.head); }
  removeTail() { if (this.tail) this.removeNode(this.tail); }
}

The removeNode(node) method is the entire reason doubly linked lists exist in serious systems. When you have a direct reference to a node — not a value you need to search for, but the actual node object — deletion is just pointer surgery. Four pointer updates. Done.

This changes everything for the use case that actually matters.

The One Pattern Where Linked Lists Are Irreplaceable

The LRU (Least Recently Used) cache is the canonical real-world use case — and it's worth understanding in detail because it appears in CDN edge nodes, database query planners, CPU cache replacement policies, DNS resolvers, and web server in-memory caches.

The problem: you have a cache with limited capacity. When it's full and you need to add something new, you evict the item that was accessed least recently. You need:

O(1) lookup: "Is this key in the cache?"
O(1) insert: "Add this new key-value pair"
O(1) eviction: "Remove the least recently used item"
O(1) promotion: "This key was just accessed, move it to 'most recently used'"

An array can't do this. When you access an item, you need to move it to the "recently used" position — that's O(n) shifting. A hash map alone can't do it either — it has no concept of order.

The solution is a doubly linked list paired with a hash map:

class LRUCache {
  constructor(capacity) {
    this.capacity = capacity;
    this.map = new Map();       // key → node (O(1) lookup)
    this.list = new DoublyLinkedList(); // ordered by recency
  }

  get(key) {
    if (!this.map.has(key)) return -1;

    const node = this.map.get(key);
    this.list.removeNode(node);   // O(1) — we have the node directly
    this.list.prepend(node.value); // O(1) — move to head (most recent)
    this.map.set(key, this.list.head);

    return node.value.val;
  }

  put(key, val) {
    if (this.map.has(key)) {
      this.list.removeNode(this.map.get(key)); // O(1)
    } else if (this.list.size >= this.capacity) {
      // evict the tail — it's the least recently used
      this.map.delete(this.list.tail.value.key);
      this.list.removeTail(); // O(1)
    }

    this.list.prepend({ key, val }); // O(1)
    this.map.set(key, this.list.head);
  }
}

Every operation is O(1). The hash map gives instant lookup. The doubly linked list maintains order and provides O(1) removal because we store the node reference in the hash map — we never search for the node, we go directly to it.

This is the move that makes the whole structure work. The hash map stores node references, not values. When we access a key, we pull the node directly out of the middle of the list and move it to the head — no traversal. That's only possible with a doubly linked list where removeNode doesn't require knowing where the node is in the sequence.

The Honest Comparison

Most tutorials give you a comparison table. Here's one that's actually honest about modern hardware:

Operation	Array	Singly LL	Doubly LL
Access by index	O(1)	O(n)	O(n)
Search by value	O(n)	O(n)	O(n)
Insert at head	O(n) — shift all	O(1)	O(1)
Insert at tail	O(1) amortized	O(n) or O(1) w/ tail ptr	O(1) w/ tail ptr
Delete at head	O(n) — shift all	O(1)	O(1)
Delete in middle (by value)	O(n) find + O(n) shift	O(n) find + O(1) remove	O(n) find + O(1) remove
Delete by node reference	—	—	O(1) ← the whole game
Memory per element	Low (just data)	Medium (+1 pointer)	Higher (+2 pointers)
Cache performance	Excellent	Poor	Poor
Traversal speed in practice	~10–100x faster	Slow	Slow

The "delete by node reference" row is the one that matters. It's the entire reason doubly linked lists exist in production systems. Everything else, arrays do better or equal for most workloads — because of cache locality, not because of Big-O.

If you're choosing between array and linked list for a problem where you're iterating through data, an array wins even if your Big-O analysis says they're equal. The constant factor of cache performance is that significant.

When to Actually Use Each One

Reach for a singly linked list when:

You're building a stack and want textbook clarity (though an array works fine here too)
You're implementing something where you only ever add/remove from one end
Memory is extremely tight and you can't afford the extra prev pointer

Reach for a doubly linked list when:

You need O(1) deletion and you'll have direct node references (LRU cache, undo history where each action holds its own node)
You're building anything that requires backward traversal without a second pass
You're implementing a deque (double-ended queue) with O(1) operations at both ends

Don't reach for either when:

You're just storing and iterating over data — use an array
You need frequent random access — use an array
You're searching by value — use a hash map or sorted array with binary search

The deeper point: linked lists are most valuable not as standalone structures but as the ordered component inside composite structures. The LRU cache doesn't use a linked list instead of a hash map — it uses them together. That combination produces something neither could achieve alone. That's the real lesson.

Where They're Already Running in Your Stack

Without writing a single line of linked list code, these structures are running around you right now:

Node.js — The timers module maintains doubly linked lists to track setTimeout/setInterval expiry. The http module uses them for connection pools.

V8 (Chrome's JS engine) — The garbage collector uses linked list-like structures to track object generations and manage the free list of available memory blocks.

Redis — LPUSH/RPUSH/LPOP/RPOP operate on a linked list. Redis lists are actually a hybrid (ziplist for small sizes, linkedlist for large), but the interface is a linked list.

Linux kernel — The process scheduler's run queue is a doubly linked list. The list_head structure in the kernel source is one of the most used data structures in any OS codebase.

Your browser's navigation — Every window.history.back() and window.history.forward() is a doubly linked list traversal.

You've been using linked lists constantly. You just didn't know their name.

The Real Reason to Learn This

Interview prep is the wrong motivation to learn linked lists. The right motivation is this: understanding why a doubly linked list paired with a hash map gives you O(1) everything for an LRU cache — that kind of reasoning is what separates engineers who design systems from engineers who just implement requirements.

When someone at a senior system design interview says "we need an LRU cache with O(1) get and put" and you immediately know the structure — and, more importantly, you know why that structure works at the hardware level — that's not trivia. That's thinking.

The data structure is simple. The thinking behind it isn't.

Code examples are in JavaScript for readability. The concepts apply identically in Python, Go, Rust, or any other language. In production systems you'd typically use the language's built-in deque or list structures rather than rolling your own — but understanding the internals is exactly the point.

Cheers !

Monolithic vs Microservices

Islam Hafez — Sun, 21 Jun 2026 10:02:55 +0000

Intro

Ever heard the words "monolithic" and "microservices" tossed around in tech conversations? Don't worry if they sound a bit confusing – you're not alone! These terms are hot topics in the world of software design, and for good reason.

In this article, we're going to break down what monolithic and microservices mean. We'll compare them in simple terms and talk about when you might want to use each one.

Monolithic and microservices are both types of software architecture. In simple terms, architecture is just a fancy word for the overall design of a computer program - it's the plan that lays out how all the pieces of the software will fit and work together. These are just different ways to build web applications.

We are going to understand each architecture with the help of an example.

We'll consider designing an online travel booking web application that offers hotel reservations, flight bookings, and train ticket purchases, along with payment processing and user account management for understanding these architectures.

We will be discussing these architectures concerning backend logic.

Monolithic

In a monolithic architecture, we would design the application as a single, unified system. All the code for every feature would reside within one codebase(project). This includes:

Hotel booking functionality
Flight reservation system
Train ticket booking
Payment processing
User authentication (sign-up and login)

The entire codebase, encompassing all these functions, operates as one cohesive unit.

In a monolithic architecture, you build and deploy the entire application as one single unit. This means you have to use just one technology stack for the whole app, whether it's Java with Spring Boot, Python with Django, JavaScript with Node.js, or any other combination.

Monolithic architecture is often the go-to choice for small startups, personal projects, or companies that don't deal with a huge user base.

Benefits of Monolithic Architecture

Easier to Develop:

You work with a single codebase, which means less complexity to manage.
All parts of your application are in one place, making it simpler to understand the overall structure.
When you need to add new features, you can easily integrate them into the existing codebase.
Testing is more straightforward because you can run all tests in one go.

Easier to Manage:

Deployment is simpler because you're dealing with just one application.
You only need to monitor and maintain a single system.

These advantages make monolithic architecture a practical choice for smaller projects or teams that want to get their application up and running quickly without dealing with the complexities of more distributed systems.

Challenges with Monolithic Architecture

Some major issues that come with using a monolithic architecture include:

Single Point of Failure

In a monolithic setup, all parts of the application are tightly interconnected. This means if something goes wrong in one area—like a bug or performance issue—it can affect the entire system. Imagine if a glitch in one feature causes the whole app to crash, leaving users unable to access anything. This dependency on a single codebase makes the system vulnerable to widespread failures, impacting reliability and user experience. It also limits flexibility in updating and scaling different parts of the app independently, which can lead to more downtime and operational headaches.

Redeployment

Imagine we need to make a minor update to improve the payment functionality in our application. Even though it's a small change, we have to redeploy the entire app. This can be incredibly frustrating. A simple tweak to one part of the system forces us to go through the whole deployment process again, involving all components of the app, even those not affected by the change. This not only wastes time and resources but also increases the risk of introducing new bugs and downtime, making the process unnecessarily cumbersome.

Scaling Issues

When user traffic spikes, a monolithic application can struggle to cope. Every part of the app—from hotel bookings to payments—feels the strain on the single server. This overload leads to slow responses, timeouts, and errors, frustrating users.

To manage increased traffic, you typically need to scale horizontally by deploying multiple copies of the entire app across many servers.

However, this method is inefficient because it requires replicating the entire application, even for parts that don't need more resources. And with scaling, comes a hefty bill to manage.

Balancing performance needs with cost efficiency becomes challenging. Scaling down during quieter periods also poses challenges, including safely decommissioning excess servers without disrupting service and managing data consistency.

These challenges highlight why monolithic architectures struggle with fluctuating loads and why organizations often turn to more flexible solutions like microservices, which offer better scalability and cost management capabilities.

Lots of Dependence(Rigid)

If too many developers are working on the same codebase, even making a small change can become problematic. Each change can impact other parts of the application, leading to conflicts and dependencies that need to be resolved. This often results in longer development times, as developers must coordinate closely, perform extensive testing, and handle merge conflicts. The interdependence of various components means that a small tweak by one developer might require adjustments or fixes in seemingly unrelated parts of the code, complicating the development process and slowing down progress.

Solution

Enter microservices:

And one of the pioneers in adopting microservices was the renowned media streaming platform, Netflix. Originally built on a monolithic architecture, Netflix faced significant challenges as its user base grew exponentially. With millions of subscribers globally streaming movies and TV shows simultaneously, the monolithic approach struggled to handle the increasing traffic efficiently.

This led Netflix to innovate and transition towards a microservices architecture, marking a pivotal shift in how modern applications are designed and operated. Today, Netflix operates using hundreds of microservices to power their application. This architectural shift has become a standard for high-traffic applications.

Netflix’s adoption of microservices revolutionized the way large-scale applications handle scalability, flexibility, and user experience.

For more info check out these blogs published by Netflix:
https://netflixtechblog.com/tagged/microservices

Similarly, Atlassian noted in their monolithic vs microservices blog:

In January 2016, we had about 15 total microservices. Now we have more than 1300. We moved 100K customers to the cloud, built a new platform along the way, transformed our culture, and ended up with new tools. We have happier, autonomous teams and a better DevOps culture.Microservices may not be for everyone. A legacy monolith may work perfectly well, and breaking it down may not be worth the trouble. But as organizations grow and the demands on their applications increase, microservices architecture can be worthwhile.

Reference:
https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith

Microservices

To sum up microservices in one phrase: don't put all your eggs in one basket.

In a microservices setup, we take a big application and break it down into smaller, manageable pieces, each handling a specific function. These smaller pieces, or services, operate independently, have their codebase, and can be developed and deployed on their own. This makes them loosely connected, allowing for greater flexibility and easier management.

Microservices architecture is generally not adopted by small teams or small organizations. It is more commonly implemented by large companies with millions of users and thousands of developers, such as Amazon, Uber, Netflix, Airbnb, etc.

Deciding the Number of Microservices

When transitioning from a monolithic application to a microservices architecture, we need to divide the single, unified application into multiple smaller, independent services.

But the question arises: how many independent services should a monolithic application be divided?

There's no exact answer or strict rule for this—it varies from company to company based on their specific business needs. For example, in our monolithic travel application, the company might choose to split it into smaller services like payments, hotel bookings, flight bookings, authentication, and train bookings. This way, the monolithic travel application becomes five separate microservices, each handling a specific part of the application and working together.

Benefits of Using Microservices

Independent Deployment (Isolation development and Deployment)

One of the key advantages of a microservices architecture is the ability to independently deploy individual services. The independent deployment results in major cost savings, lower downtime, and more time saved as we don't have to redeploy the whole application. In this approach, each microservice has its own:

Codebase
Development team
Database
CI/CD pipeline

Independent deployment means you can update, modify, or scale a single service without affecting the entire application. Changes to one service don't require redeploying the whole system.

Flexible Scaling (granular scaling)

Flight Booking Service: During a flash sale on airline tickets...
Hotel Booking Service: If it's the off-season...
Payment Service: Increased activity...
User Authentication and Signup Service: Moderate scaling...
Train Booking Service: Base capacity...

Technology Flexibility

Each service can use different technologies best suited for its needs.

But how do microservices interact with each other?

There are three major ways for microservices to communicate:

Synchronous Communication
Asynchronous Communication
Service Mesh

Synchronous Communication

API Endpoints
Request-Response Mechanism
Real-Time Interaction

Asynchronous Communication

Using Message Brokers

Producer → Broker → Consumer

Service Mesh: Brief overview

A service mesh is a system that helps microservices communicate efficiently and securely using sidecar proxies.

Issues with Microservices

Complex to Develop

Management Overhead

High Infrastructure Cost

Because of these challenges, small teams or startups often prefer not to use microservice architecture.

Summary: Choosing Between Monolithic and Microservices

When to Use Monolithic Architecture:

Simple Apps
Small Teams
Lower Costs
Quick Development
Easy Management

When to Opt for Microservices:

Big and Complex Apps
Need to Scale
Multiple Teams
Frequent Updates
High Reliability
Different Tech Needs

This article is based on and adapted from content originally published by Unlogged.

Cheers!

Happy Coding.

TOON: Token-Oriented Object Notation – A Complete Guide for LLM Data Efficiency

Islam Hafez — Thu, 11 Dec 2025 12:19:14 +0000

Token-Oriented Object Notation (TOON) is a compact, human-readable encoding of the JSON data model, specifically designed to minimize tokens and simplify structure for Large Language Models (LLMs). It acts as a drop-in, lossless representation of JSON, allowing developers to use familiar JSON programmatically while converting to TOON for efficient AI input.

TOON merges YAML’s indentation-based structure for nested objects with CSV-style tabular arrays for uniform data. Its primary strength is with uniform arrays of objects—multiple fields per row with consistent structure—achieving compactness similar to CSV, while maintaining explicit schema information for reliable LLM parsing. For deeply nested or non-uniform data, standard JSON may remain more efficient.

Why TOON?

With AI becoming more accessible, context windows are expanding, but tokens still cost money. Standard JSON is verbose:

{
  "context": {
    "task": "Our favorite hikes together",
    "location": "Boulder",
    "season": "spring_2025"
  },
  "friends": ["ana", "luis", "sam"],
  "hikes": [
    {"id": 1, "name": "Blue Lake Trail", "distanceKm": 7.5, "elevationGain": 320, "companion": "ana", "wasSunny": true},
    {"id": 2, "name": "Ridge Overlook", "distanceKm": 9.2, "elevationGain": 540, "companion": "luis", "wasSunny": false},
    {"id": 3, "name": "Wildflower Loop", "distanceKm": 5.1, "elevationGain": 180, "companion": "sam", "wasSunny": true}
  ]
}

TOON conveys the same information with fewer tokens, combining YAML-style indentation and CSV-style tabular arrays:

context:
  task: Our favorite hikes together
  location: Boulder
  season: spring_2025
friends[3]: ana,luis,sam
hikes[3]{id,name,distanceKm,elevationGain,companion,wasSunny}:
  1,Blue Lake Trail,7.5,320,ana,true
  2,Ridge Overlook,9.2,540,luis,false
  3,Wildflower Loop,5.1,180,sam,true

Key Features

Token-Efficient & Accurate: TOON achieves up to 74% accuracy versus JSON’s 70% while using ~40% fewer tokens in mixed-structure benchmarks.
JSON-Compatible: Encodes objects, arrays, and primitives with deterministic, lossless round-trips.
LLM-Friendly: Explicit [N] lengths and {fields} headers provide clear schema information for reliable parsing.
Minimal Syntax: Indentation instead of braces, minimal quoting, YAML-like readability with CSV compactness.
Tabular Arrays: Uniform arrays collapse into tables, declaring fields once and streaming row values line by line.
Multi-Language Ecosystem: Implementations exist in TypeScript, Python, Go, Rust, .NET, and more.

Media Type & File Extension

File extension: .toon
Media type: text/toon
Always UTF-8 encoded.

When Not to Use TOON

Deeply nested or non-uniform structures: JSON compact may use fewer tokens.
Semi-uniform arrays: Token savings are reduced.
Pure tabular data: CSV may remain slightly smaller than TOON.
Latency-critical applications: Test performance against your specific model and setup.

Benchmarks

TOON consistently reduces token usage while improving comprehension across four major LLMs:

Efficiency Score: Accuracy % ÷ Tokens × 1,000
Mixed-Structure Track: TOON uses 39.6% fewer tokens while improving accuracy over standard JSON.
Flat-Only Track: TOON slightly exceeds CSV token count (+6%) for added structure and reliability.

Detailed per-model benchmarks show TOON outperforms JSON, YAML, and XML across varied datasets while remaining competitive with CSV on flat tabular data.

Installation & Quick Start

CLI (no installation required):

npx @toon-format/cli input.json -o output.toon
echo '{"name": "Ada", "role": "dev"}' | npx @toon-format/cli

TypeScript Library:

npm install @toon-format/toon

Example usage:

import { encode } from '@toon-format/toon'

const data = {
  users: [
    { id: 1, name: 'Alice', role: 'admin' },
    { id: 2, name: 'Bob', role: 'user' }
  ]
}

console.log(encode(data))
// users[2]{id,name,role}:
//   1,Alice,admin
//   2,Bob,user

Playgrounds & Editor Support

Official Playground: Convert JSON to TOON in real time, compare token counts, share experiments.
Editor Support: VS Code extension, Tree-sitter grammar, Neovim plugin, and YAML highlighting for other editors.

Using TOON with LLMs

TOON’s structure is self-documenting. When prompting LLMs:

Wrap data in TOON code blocks.
Provide [N] lengths and {fields} headers.
Use tab delimiters for token efficiency.

Other Implementations

Official: .NET, Dart, Go, Java, Julia, Python, Rust, Swift
Community: Apex, C++, Clojure, Crystal, Elixir, Scala, Lua, OCaml, Perl, PHP, R, Ruby, Kotlin

TOON is stable, but still evolving. Contributions, feedback, and experimentation are encouraged.

Summary:
TOON provides a token-efficient, readable, LLM-friendly alternative to JSON, especially for uniform arrays of objects. It reduces token costs, increases parsing reliability, and is easy to integrate with existing JSON workflows. For developers working with LLMs at scale, TOON is a powerful addition to the toolset.