I built a pretty ambitious project, shared part of it with the community through "silentJson", and wrote a detailed article explaining how to achieve some pretty crazy performance results.

The results were so unrealistic to some people that I was accused of spam, and the article was removed from a few subreddits.

Still, I'm genuinely grateful that many people at least took the time to read the articles, and that some of them actually appreciated the work.

So, here is the continuation.

The problem isn't only that we need to remove unnecessary layers, conversions, or simplify the logic. The bigger problem is that all of this is actually standard practice in production systems. And most people simply don't notice it anymore.

Let me give you a hint where to look.

Take PL/pgSQL, for example. You can put the logic directly inside the database.

Or Elasticsearch. It works in a similar way.

You probably use approaches like these all the time.

And while PostgreSQL itself doesn't necessarily give you some massive raw speed advantage, it can still give you a huge overall performance win because you are not constantly moving information through layers of OOP abstractions and paying the cost of all those calls and transformations.

The business logic is already where it needs to be.

You can use the same idea in your own applications.

But for some reason, we often care more about creating interfaces and generics so that we can mock everything in unit tests instead of simply writing integration tests.

This can significantly reduce the load on the system and, more importantly, make your tests validate real scenarios instead of proving that "sum(1, 2)" returns 3.

So where do you start?

Take a piece of paper.

Write down the actual goal of the system, what you have, and what you want to achieve.

Use blocks, lists, arrows, whatever works for you.

At this stage, completely forget about the programming language.

Seriously.

If you start thinking about Go, Java, Rust, interfaces, frameworks, or whatever else too early, you will probably start designing around the language instead of designing around the problem.

First, work out how the data should actually flow through the system.

Only at that point should you start thinking about what data you need, how it should be stored, and, perhaps even more importantly, what should not be stored or processed at all.

Then start writing code.

But write it according to the data flow and decomposition you already designed.

At every stage, use only what is actually necessary.

For example: maps, interface{}, channels, mutexes, goroutines.

Sometimes it is incredibly convenient to throw together a worker pool using channels. It's simple, readable, and often works very well.

But do you actually need it?

Creating goroutines isn't free.

A WaitGroup isn't automatically the best solution just because it's convenient.

And combining maps with mutexes can very quickly turn into an adventure where you're trying to figure out who locked what, when it happened, and why something never got unlocked.

Sometimes a simple slice, struct, or primitive type is all you need.

Programming has spent decades developing good ways to work with data efficiently. Look at the natural primitives we already have.

Take JSON.

It is simple, universal, and fast enough for an enormous number of real-world applications.

Yet many people consider JSON "slow".

Usually, the problem isn't JSON itself.

The problem is what you put inside it and what you make it do.

Add a "time.Time", a "map[string]interface{}", or several layers of dynamic structures, and suddenly you get the performance penalty you were blaming on JSON.

The same principle applies everywhere else.

If the job is to store data, store it.

If the job is to return data, return it.

Don't build obstacles in between.

The fewer steps the information has to go through, the faster it reaches its destination.

And don't try to return more than you actually have.

Separate responsibilities.

If a service is supposed to provide data, it should provide data.

If a BFF is supposed to compose data, let it compose data.

And let it do that as quickly and simply as possible.

It shouldn't be transforming everything just because it can.

A BFF doesn't need to contain your business logic.

Wait.

What about business logic?

This is where things get interesting.

Business logic can actually operate on different levels.

Some logic changes the data itself. Other logic changes how that data is presented.

The first kind belongs as close as possible to the point where the data is created, retrieved, or indexed.

The second kind can live at the composition layer, frontend, or a dedicated business layer.

Where exactly you put it depends on the architecture and business requirements of the project.

And that's why the architecture should be designed before you start writing the code.

Once the data flow is clear, you can look at the system and ask a much more useful question:

"Where is the bottleneck?"

Then remove everything on the path that creates an unnecessary restriction.

Profile your application.

If you don't know how, ask an LLM. There is no shame in that.

When you've done all of this and finally discover that the bottleneck isn't your architecture anymore, but the hardware itself, then you can start asking whether that abstraction, interface, mock, or extra layer is really worth its cost.

Especially when the only reason for adding it was to prove that one tiny function correctly calculates 2 + 2.

I'm curious how other people approach this.

How do you design, develop, and profile your systems?

And how do you decide when an abstraction is actually useful and when it is just another layer between the data and its destination?

From Frameworks to Metal: How to Reach 102,000 RPS with Go and Stop Being Afraid of High Load

There comes a point in a developer's career when you start getting tired of constraints.

Standard frameworks. Ready-made ORMs. Abstraction on top of abstraction. Layers that exist to hide other layers. And somewhere at the bottom of all of it, a simple map that just wanted to find a key.

At first, it's convenient. Then it gets cramped.

Eventually, you start wanting to do the opposite: remove everything unnecessary and see what the machine can actually do when you stop getting in its way.

That's how my current project evolved — a high-load product aggregator written in Go.

No SQL in the hot path. No heavyweight frameworks. No standard JSON marshaler. Just mmap, custom indexes, direct memory access, and a little bit of unsafe.

And the result turned out to be somewhat more interesting than I expected.

---

From Syntax to Hardware

Learning Go usually starts innocently enough.

First:

go func() {
    ...
}()

Then come:

• goroutines;
• channels;
• sync.Mutex;
• WaitGroup;
• sync.Map;
• sync.Pool;
• atomic;
• worker pools;
• queues;
• caching;
• Docker;
• microservices.

And then real-world load arrives.

Suddenly, the question is no longer:

> Do you know how to write concurrent code?

The question becomes:

> How much work actually needs to be done for a single request?

That's a completely different level of optimization.

Because if a request goes through ten abstractions, creates several objects, performs multiple data conversions, hits a database, retrieves the data, converts it into structs, and then converts those structs back into JSON — no amount of atomic is going to save you.

And that's when the evolution starts going in reverse.

Slices instead of unnecessary maps.

Direct memory access instead of intermediate objects.

Atomic operations where an atomic is actually enough.

mmap instead of constant I/O.

Indexes instead of calculations.

Raw bytes instead of conversions.

And eventually, one question:

> What if we simply remove everything from the hot path that isn't absolutely necessary?

---

Makodb: A Database That Doesn't Try to Be SQL

The project is built around a custom mmap-based KV database — Makodb.

Its job is deliberately narrow: serve data as quickly as possible for read-heavy workloads.

There is no SQL query, ORM, or conversion pipeline in the hot path:

storage
   ↓
object
   ↓
ORM
   ↓
struct
   ↓
JSON

Instead:

mmap
  ↓
index
  ↓
docID
  ↓
raw data
  ↓
JSON buffer

The main principles are:

• lock-free reads;
• one write lock per shard;
• mmap;
• sharding;
• sorted uint64 indexes;
• merge-style intersection/union;
• direct range queries;
• sort indexes;
• minimal allocations;
• no objects in the hot read path.

One particularly interesting component is the turbo index.

An index is simply a sorted array of uint64 values:

[docID1][docID2][docID3]...[docIDN]

So intersecting two indexes becomes a standard merge operation:

A:  1  4  7  12  20  35
B:  2  4  8  12  19  35

AND:

    4        12       35

No temporary maps.

No temporary objects.

No O(n*m).

Just two pointers and sequential memory access.

---

700,000+ Landing Pages and 4 Million+ Products

This isn't a synthetic benchmark with a single Hello World endpoint.

The actual project contains:

• 700k+ landing pages;
• 4M+ products;
• categories;
• slugs;
• sorting;
• filters;
• price ranges;
• text indexes;
• pagination;
• different combinations of parameters.

And one principle is particularly important:

> There is no special magic for page 1 and page 500,000.

There is no situation where the first page is instant and deep pagination suddenly turns into OFFSET 500000.

There is an index.

The required position can be accessed directly.

Sorting is also not performed from scratch for every request — prebuilt sort indexes handle it.

Filtering becomes a set of operations on indexes.

---

And Then It Turned Out the Database Wasn't the Problem

This was probably the most interesting stage.

Under normal load, data queries were completing in roughly:

0.161–3 ms.

But the browser was showing considerably more.

So I started measuring.

Data retrieval — fast.

Filtering — fast.

Indexes — fast.

Result composition — fast.

And then:

w.Write(...)

Suddenly, it became clear that sending the result could sometimes cost more than computing it.

That's where things got interesting.

---

Goodbye, encoding/json

The standard:

json.NewEncoder(w).Encode(v)

is perfectly fine for most applications.

But if the goal is to squeeze every possible bit of performance out of a single machine, the standard JSON marshaler becomes expensive.

So I built SilentJSON.

The idea is simple:

> We already know the response structure. Why should the runtime figure it out again?

Instead of dynamically inspecting types through reflection, the serializer uses precomputed field metadata, offsets, and specialized marshal functions.

Conceptually:

struct
  ↓
known offset
  ↓
direct memory access
  ↓
append bytes
  ↓
JSON

Instead of:

interface{}
   ↓
reflect
   ↓
temporary object
   ↓
conversion
   ↓
JSON

And this leads to another important principle.

---

If the Structure Is Known, Don't Make It Universal

Universality is usually considered a virtue.

But universality has a cost.

For example:

map[string]interface{}

is convenient.

But you pay for that convenience in:

• predictability;
• allocations;
• cache locality;
• type safety;
• serialization speed.

For a narrow, specialized project, you can make a completely different tradeoff.

For example:

[]{
    key,
    weight,
    value
}

Or a specialized raw type.

Or a response structure whose layout is known in advance.

It's less universal.

But extremely transparent.

And fast.

---

The Most Revealing Experiment: GET vs HEAD

At some point, there was a very simple way to test the hypothesis.

If HEAD executes the entire internal request logic but doesn't send the response body, we can compare it directly with a normal GET.

The results were very revealing.

At:

Concurrency: 5800
Duration:    60s

HEAD

Total: 6,167,463 requests
RPS:   102,339
Errors: 0.0%

Average latency:

/shop                 44 ms
/shop/{category}      45 ms
/shop/{slug}          92 ms
/products              44 ms
/products/turbo        45 ms
/categories/tree      46 ms

Maximum latency:

310–483 ms

In other words, the entire internal workload can be processed at more than 100,000 requests per second.

Now the same server, the same workload, the same concurrency — but a real GET.

GET

Total: 3,355,057 requests
RPS:   55,632
Errors: 0.0%

Average latency:

/shop                 84 ms
/shop/{category}      86 ms
/shop/{slug}         164 ms
/products              81 ms
/products/turbo        77 ms
/categories/tree      81 ms

There it is.

Almost a factor of two.

Not search. Not indexes. Not filtering. Not the database.

The result has to be assembled and physically pushed out of the machine.

---

Where the Algorithm Ends and Physics Begins

The architecture now looks roughly like this:

                    102k RPS
                       │
                       ▼
             ┌─────────────────┐
             │    Go / CPU     │
             │                 │
             │     Makodb      │
             │     indexes     │
             │     filters     │
             │     business    │
             └────────┬────────┘
                      │
                  JSON ready
                      │
                      ▼
             ┌─────────────────┐
             │ output pipeline │
             │                 │
             │ memory → kernel │
             │ → socket → NIC  │
             └────────┬────────┘
                      │
                      ▼
                   ~55k RPS

And this is where it gets slightly funny.

Because the application is already saying:

> "I can do more."

And the hardware responds:

> "Where exactly are you planning to put all those bytes?"

---

5,800 Concurrent Requests

At 5800 concurrent requests, the system reached approximately:

55–56k RPS of full GET requests.

And the interesting part is that it doesn't collapse.

0 errors
0.0%

No avalanche of timeouts.

No gradual degradation into death.

No sudden throughput collapse.

It simply reaches its physical ceiling.

---

What Happens at 105,800 Concurrent?

Naturally, the next question was:

> What if we push it harder?

So:

go run main.go -c 105800 -d 60s

Result:

Total: 3,419,927 requests
RPS:   54,801
Errors: 0.0%

Average latency increased:

/shop             ~1.51 s
/category         ~1.52 s
/slug             ~3.03 s
/products         ~1.51 s
/products/turbo   ~1.51 s
/categories       ~1.51 s

But the server didn't die.

That's an important distinction.

The system couldn't process more than roughly 55k RPS — but it held that ceiling under an absurd number of concurrent requests.

So as concurrency increases:

200
  ↓
800
  ↓
2800
  ↓
5800
  ↓
15800
  ↓
55800
  ↓
105800

throughput eventually stops growing.

But it doesn't collapse.

We hit a plateau.

---

Load Test Series

Concurrency	RPS	Avg latency	Errors
200	36,209	2–9 ms	0%
800	53,202	7–23 ms	0%
2,800	55,781	34–78 ms	0%
5,800	55,632	77–164 ms	0%
15,800	55,868	219–448 ms	0%
55,800	55,061	794–1,599 ms	0%
105,800	54,801	1,507–3,025 ms	0%

And that's probably the most interesting graph in the whole experiment.

RPS
60k ┤
    │        ┌─────────────────────────────────────
55k ┤────────┘
    │
50k ┤
    │
40k ┤
    │
30k ┤
    │
20k ┤
    │
10k ┤
    └──────────────────────────────────────────────
      200  800  2.8k  5.8k  15.8k  55.8k  105.8k

After roughly 2–3 thousand concurrent requests:

throughput becomes almost horizontal.

What keeps increasing is latency.

That's classic behavior for a system that has reached a resource ceiling.

---

The Funny Part: This Isn't a Server Cluster

This experiment wasn't performed on some enormous fleet of machines.

There wasn't:

load balancer
    ↓
20 application servers
    ↓
10 database servers
    ↓
Redis cluster
    ↓
Kafka cluster

It's one machine.

Ordinary workstation/home-server hardware.

And that's exactly why the experiment became interesting.

At one point I used to test what Go could do with a simple Hello World.

And I remember a very different picture: after a few hundred requests, things started going south.

Here:

5,800 concurrent
→ ~55k GET RPS

5,800 concurrent
→ ~102k HEAD RPS

105,800 concurrent
→ ~55k GET RPS
→ 0 errors

At some point, you stop asking:

> "How do I optimize Go?"

And start asking:

> "Where exactly does the program end and the computer begin?"

---

Why Does This Work?

1. Minimal Work Per Request

The main secret isn't some magical function.

It's much more boring:

> A request should do as little work as possible.

If the data is already indexed, don't search for it.

If the sort order is already known, don't sort it.

If two conditions can be intersected using a merge operation, don't build another map.

If the JSON structure is known, don't discover it through reflection.

If the document already lives in mmap, don't drag it through several intermediate representations.

---

2. Indexes Instead of Computation

A product may have indexes for:

category
brand
price
rating
date
text
...

A query such as:

category = electronics
AND
brand = x
AND
price = 5000..50000
ORDER BY price DESC

doesn't become:

find all products
→ check category
→ check brand
→ check price
→ sort everything
→ take 60

Instead:

category index
       ↓
      AND
       ↓
brand index
       ↓
      AND
       ↓
price range
       ↓
sort index
       ↓
page

Most of the work is performed on compact numeric indexes.

---

3. mmap

Data lives in memory-mapped storage.

The read path doesn't have to constantly perform traditional filesystem I/O.

Conceptually:

disk file
   │
   ▼
 mmap
   │
   ▼
memory address
   │
   ▼
read

This is particularly well suited to read-heavy workloads.

---

4. Lock-Free Read Path

Writes are a different story.

But reads shouldn't have to wait for other reads.

There is no global:

mu.Lock()
...
mu.Unlock()

on every request.

The hot read path uses atomic reads and direct memory access.

Sharding additionally distributes write contention.

---

5. JSON Became the Last Enemy

And this is probably the most important conclusion of the entire experiment.

After optimizing the database, indexes, and search, it turned out that the next major problem wasn't retrieving the data.

It was sending it.

That's why moving to a specialized JSON marshaler made such a noticeable difference.

And then something even more interesting became apparent:

> Even when JSON is already as lean as possible, the bytes still have to physically leave the machine.

At that point, no architectural abstraction can help.

The bytes have to move.

---

Where Is the Real Bottleneck Now?

Very roughly:

request
   │
   ├── routing
   ├── filtering
   ├── index intersection
   ├── sorting
   ├── document lookup
   ├── JSON composition
   │
   └── network output

The first stages have become fast enough that optimizing them further no longer produces the biggest gains.

Now the problem is much more physical:

throughput ≈ available bandwidth / response size

Of course, the real system is more complicated.

But at this scale, that's already the right way to think about it.

If a response is N bytes and the server needs to send tens of thousands of those responses every second, we very quickly stop talking about algorithms.

We start talking about:

how many bytes per second the entire system can move.

---

And That's Where It Gets Really Funny

You optimize the algorithm.

Then memory.

Then indexes.

Then JSON.

Then unnecessary conversions.

And eventually you discover:

CPU:
    "I can still go."

Makodb:
    "I can still go."

Indexes:
    "We're barely working."

JSON:
    "I've already been put on a diet."

Network stack:
    "Guys..."

PCIe:
    "Slow down."

NIC:
    "Where exactly are you taking all those bytes?"

And this is actually a beautiful stage of optimization.

Because it means you have finally reached the hardware.

---

What I Took Away from the Experiment

The most important result wasn't 102,339.

It wasn't even 55,632 RPS.

The real conclusion is much simpler:

> High load itself isn't scary. The scary part is how much work you force the system to perform for each request.

If a request requires:

SQL
→ ORM
→ struct
→ reflection
→ map
→ conversion
→ JSON
→ copy
→ socket

then high load quickly turns into a fight against your own architecture.

If the request looks more like:

request
  ↓
index
  ↓
memory
  ↓
bytes
  ↓
socket

then suddenly a single ordinary machine can perform tens of thousands of these operations every second.

And if you remove the response body and leave only the internal processing, you get more than 100,000 requests per second.

---

Final Numbers

On the current hardware, the experiment demonstrated:

Full GET

≈55,000 RPS

with:

• 5,800 concurrent requests;
• real JSON;
• real business logic;
• filtering;
• sorting;
• index operations;
• 0.0% errors.

HEAD

102,339 RPS

with the same internal request processing and 0.0% errors.

Extreme concurrency

105,800 concurrent requests

without the server crashing and without errors.

Load

Millions of requests per minute.

And after a certain level of concurrency, the system doesn't start dying.

It simply says:

> "I can't go any faster. But I'm not going to fall over either."

And perhaps that's the best result a load test can give you.

Not the biggest number.

But a predictable plateau.

Because a server that turns into a pumpkin when you go from 5,000 to 100,000 concurrent requests is a problem.

A server that says:

> "My ceiling is here. Beyond that, things will simply get slower."

is already a system you can reason about, plan around, and scale.

And that leaves the most interesting question:

If the algorithms are no longer the bottleneck, JSON is already on a diet, and the CPU still has room — how far can we go if the next optimization target is no longer the code, but the path the bytes take from memory all the way to the network interface?

[user nodownload]$ go run main.go -c 5800 -d 60s
[1m0s] Running... shop:2180588 shopCat:1246559 shopSlug:1559589 products:500109 turbo:312322 cats:436086
=== HEAD Load Test Results ===
Duration:   1m0.214s
Concurrency: 5800

GET /shop                 2182135 reqs  36240 req/s  avg=44ms     min=12ms     max=353ms    err=0.0%
GET /shop/{category}      1247457 reqs  20717 req/s  avg=44ms     min=12ms     max=371ms    err=0.0%
GET /shop/{slug}          1561944 reqs  25940 req/s  avg=91ms     min=40ms     max=494ms    err=0.0%
GET /products             500492 reqs  8312 req/s  avg=44ms     min=19ms     max=367ms    err=0.0%
GET /products/turbo       312575 reqs  5191 req/s  avg=44ms     min=16ms     max=313ms    err=0.0%
GET /categories/tree      436449 reqs  7248 req/s  avg=46ms     min=12ms     max=344ms    err=0.0%

Total: 6241052 requests, 0 errors (0.00%), 103648 req/s
[user nodownload]$ cd ../load/
[user load]$ go run main.go -c 5800 -d 60s
[1m0s] Running... shop:1182442 shopCat:675229 shopSlug:843211 products:270361 turbo:169183 cats:236240
=== Load Test Results ===
Duration:   1m0.278s
Concurrency: 5800

GET /shop                 1184095 reqs  19644 req/s  avg=84ms     min=14ms     max=650ms    err=0.0%
GET /shop/{category}      676202 reqs  11218 req/s  avg=86ms     min=17ms     max=649ms    err=0.0%
GET /shop/{slug}          845485 reqs  14026 req/s  avg=163ms    min=83ms     max=877ms    err=0.0%
GET /products             270718 reqs  4491 req/s  avg=80ms     min=18ms     max=547ms    err=0.0%
GET /products/turbo       169429 reqs  2811 req/s  avg=76ms     min=18ms     max=496ms    err=0.0%
GET /categories/tree      236530 reqs  3924 req/s  avg=80ms     min=16ms     max=552ms    err=0.0%

Total: 3382459 requests, 0 errors (0.00%), 56115 req/s

There comes a point in a developer's career when you start getting tired of constraints.

https://preview.redd.it/z3l78pja9dkh1.jpg?width=1376&format=pjpg&auto=webp&s=04224163ce49e93dad0f5081aa1ae4807a9d6dd8

Standard frameworks. Ready-made ORMs. Abstraction on top of abstraction. Layers that exist to hide other layers. And somewhere at the bottom of all of it, a simple map that just wanted to find a key.

At first, it's convenient. Then it gets cramped.

Eventually, you start wanting to do the opposite: remove everything unnecessary and see what the machine can actually do when you stop getting in its way.

That's how my current project evolved — a high-load product aggregator written in Go.

No SQL in the hot path. No heavyweight frameworks. No standard JSON marshaler. Just mmap, custom indexes, direct memory access, and a little bit of unsafe.

And the result turned out to be somewhat more interesting than I expected.

From Syntax to Hardware

Learning Go usually starts innocently enough.

First:

go func() {
    ...
}()

Then come:

• goroutines;
• channels;
• sync.Mutex;
• WaitGroup;
• sync.Map;
• sync.Pool;
• atomic;
• worker pools;
• queues;
• caching;
• Docker;
• microservices.

And then real-world load arrives.

Suddenly, the question is no longer:

>Do you know how to write concurrent code?

The question becomes:

>How much work actually needs to be done for a single request?

That's a completely different level of optimization.

Because if a request goes through ten abstractions, creates several objects, performs multiple data conversions, hits a database, retrieves the data, converts it into structs, and then converts those structs back into JSON — no amount of atomic is going to save you.

And that's when the evolution starts going in reverse.

Slices instead of unnecessary maps.

Direct memory access instead of intermediate objects.

Atomic operations where an atomic is actually enough.

mmap instead of constant I/O.

Indexes instead of calculations.

Raw bytes instead of conversions.

And eventually, one question:

>What if we simply remove everything from the hot path that isn't absolutely necessary?

Makodb: A Database That Doesn't Try to Be SQL

The project is built around a custom mmap-based KV database — Makodb.

Its job is deliberately narrow: serve data as quickly as possible for read-heavy workloads.

There is no SQL query, ORM, or conversion pipeline in the hot path:

storage
   ↓
object
   ↓
ORM
   ↓
struct
   ↓
JSON

Instead:

mmap
  ↓
index
  ↓
docID
  ↓
raw data
  ↓
JSON buffer

The main principles are:

• lock-free reads;
• one write lock per shard;
• mmap;
• sharding;
• sorted uint64 indexes;
• merge-style intersection/union;
• direct range queries;
• sort indexes;
• minimal allocations;
• no objects in the hot read path.

One particularly interesting component is the turbo index.

An index is simply a sorted array of uint64 values:

[docID1][docID2][docID3]...[docIDN]

So intersecting two indexes becomes a standard merge operation:

A:  1  4  7  12  20  35
B:  2  4  8  12  19  35

AND:

    4        12       35

No temporary maps.

No temporary objects.

No O(n*m).

Just two pointers and sequential memory access.

700,000+ Landing Pages and 4 Million+ Products

This isn't a synthetic benchmark with a single Hello World endpoint.

The actual project contains:

• 700k+ landing pages;
• 4M+ products;
• categories;
• slugs;
• sorting;
• filters;
• price ranges;
• text indexes;
• pagination;
• different combinations of parameters.

And one principle is particularly important:

>There is no special magic for page 1 and page 500,000.

There is no situation where the first page is instant and deep pagination suddenly turns into OFFSET 500000.

There is an index.

The required position can be accessed directly.

Sorting is also not performed from scratch for every request — prebuilt sort indexes handle it.

Filtering becomes a set of operations on indexes.

And Then It Turned Out the Database Wasn't the Problem

This was probably the most interesting stage.

Under normal load, data queries were completing in roughly:

0.161–3 ms.

But the browser was showing considerably more.

So I started measuring.

Data retrieval — fast.

Filtering — fast.

Indexes — fast.

Result composition — fast.

And then:

w.Write(...)

Suddenly, it became clear that sending the result could sometimes cost more than computing it.

That's where things got interesting.

Goodbye, encoding/json

The standard:

json.NewEncoder(w).Encode(v)

is perfectly fine for most applications.

But if the goal is to squeeze every possible bit of performance out of a single machine, the standard JSON marshaler becomes expensive.

So I built SilentJSON.

The idea is simple:

>We already know the response structure. Why should the runtime figure it out again?

Instead of dynamically inspecting types through reflection, the serializer uses precomputed field metadata, offsets, and specialized marshal functions.

Conceptually:

struct
  ↓
known offset
  ↓
direct memory access
  ↓
append bytes
  ↓
JSON

Instead of:

interface{}
   ↓
reflect
   ↓
temporary object
   ↓
conversion
   ↓
JSON

And this leads to another important principle.

If the Structure Is Known, Don't Make It Universal

Universality is usually considered a virtue.

But universality has a cost.

For example:

map[string]interface{}

is convenient.

But you pay for that convenience in:

• predictability;
• allocations;
• cache locality;
• type safety;
• serialization speed.

For a narrow, specialized project, you can make a completely different tradeoff.

For example:

[]{
    key,
    weight,
    value
}

Or a specialized raw type.

Or a response structure whose layout is known in advance.

It's less universal.

But extremely transparent.

And fast.

The Most Revealing Experiment: GET vs HEAD

At some point, there was a very simple way to test the hypothesis.

If HEAD executes the entire internal request logic but doesn't send the response body, we can compare it directly with a normal GET.

The results were very revealing.

At:

Concurrency: 5800
Duration:    60s

HEAD

Total: 6,167,463 requests
RPS:   102,339
Errors: 0.0%

Average latency:

/shop                 44 ms
/shop/{category}      45 ms
/shop/{slug}          92 ms
/products              44 ms
/products/turbo        45 ms
/categories/tree      46 ms

Maximum latency:

310–483 ms

In other words, the entire internal workload can be processed at more than 100,000 requests per second.

Now the same server, the same workload, the same concurrency — but a real GET.

GET

Total: 3,355,057 requests
RPS:   55,632
Errors: 0.0%

Average latency:

/shop                 84 ms
/shop/{category}      86 ms
/shop/{slug}         164 ms
/products              81 ms
/products/turbo        77 ms
/categories/tree      81 ms

There it is.

Almost a factor of two.

Not search. Not indexes. Not filtering. Not the database.

The result has to be assembled and physically pushed out of the machine.

Where the Algorithm Ends and Physics Begins

The architecture now looks roughly like this:

                    102k RPS
                       │
                       ▼
             ┌─────────────────┐
             │    Go / CPU     │
             │                 │
             │     Makodb      │
             │     indexes     │
             │     filters     │
             │     business    │
             └────────┬────────┘
                      │
                  JSON ready
                      │
                      ▼
             ┌─────────────────┐
             │ output pipeline │
             │                 │
             │ memory → kernel │
             │ → socket → NIC  │
             └────────┬────────┘
                      │
                      ▼
                   ~55k RPS

And this is where it gets slightly funny.

Because the application is already saying:

>"I can do more."

And the hardware responds:

>"Where exactly are you planning to put all those bytes?"

5,800 Concurrent Requests

At 5800 concurrent requests, the system reached approximately:

55–56k RPS of full GET requests.

And the interesting part is that it doesn't collapse.

0 errors
0.0%

No avalanche of timeouts.

No gradual degradation into death.

No sudden throughput collapse.

It simply reaches its physical ceiling.

What Happens at 105,800 Concurrent?

Naturally, the next question was:

>What if we push it harder?

So:

go run main.go -c 105800 -d 60s

Result:

Total: 3,419,927 requests
RPS:   54,801
Errors: 0.0%

Average latency increased:

/shop             ~1.51 s
/category         ~1.52 s
/slug             ~3.03 s
/products         ~1.51 s
/products/turbo   ~1.51 s
/categories       ~1.51 s

But the server didn't die.

That's an important distinction.

The system couldn't process more than roughly 55k RPS — but it held that ceiling under an absurd number of concurrent requests.

So as concurrency increases:

200
  ↓
800
  ↓
2800
  ↓
5800
  ↓
15800
  ↓
55800
  ↓
105800

throughput eventually stops growing.

But it doesn't collapse.

We hit a plateau.

Load Test Series

Concurrency	RPS	Avg latency	Errors
200	36,209	2–9 ms	0%
800	53,202	7–23 ms	0%
2,800	55,781	34–78 ms	0%
5,800	55,632	77–164 ms	0%
15,800	55,868	219–448 ms	0%
55,800	55,061	794–1,599 ms	0%
105,800	54,801	1,507–3,025 ms	0%

And that's probably the most interesting graph in the whole experiment.

RPS
60k ┤
    │        ┌─────────────────────────────────────
55k ┤────────┘
    │
50k ┤
    │
40k ┤
    │
30k ┤
    │
20k ┤
    │
10k ┤
    └──────────────────────────────────────────────
      200  800  2.8k  5.8k  15.8k  55.8k  105.8k

After roughly 2–3 thousand concurrent requests:

throughput becomes almost horizontal.

What keeps increasing is latency.

That's classic behavior for a system that has reached a resource ceiling.

The Funny Part: This Isn't a Server Cluster

This experiment wasn't performed on some enormous fleet of machines.

There wasn't:

load balancer
    ↓
20 application servers
    ↓
10 database servers
    ↓
Redis cluster
    ↓
Kafka cluster

It's one machine.

Ordinary workstation/home-server hardware.

And that's exactly why the experiment became interesting.

At one point I used to test what Go could do with a simple Hello World.

And I remember a very different picture: after a few hundred requests, things started going south.

Here:

5,800 concurrent
→ ~55k GET RPS

5,800 concurrent
→ ~102k HEAD RPS

105,800 concurrent
→ ~55k GET RPS
→ 0 errors

At some point, you stop asking:

>"How do I optimize Go?"

And start asking:

>"Where exactly does the program end and the computer begin?"

Why Does This Work?

1. Minimal Work Per Request

The main secret isn't some magical function.

It's much more boring:

>A request should do as little work as possible.

If the data is already indexed, don't search for it.

If the sort order is already known, don't sort it.

If two conditions can be intersected using a merge operation, don't build another map.

If the JSON structure is known, don't discover it through reflection.

If the document already lives in mmap, don't drag it through several intermediate representations.

2. Indexes Instead of Computation

A product may have indexes for:

category
brand
price
rating
date
text
...

A query such as:

category = electronics
AND
brand = x
AND
price = 5000..50000
ORDER BY price DESC

doesn't become:

find all products
→ check category
→ check brand
→ check price
→ sort everything
→ take 60

Instead:

category index
       ↓
      AND
       ↓
brand index
       ↓
      AND
       ↓
price range
       ↓
sort index
       ↓
page

Most of the work is performed on compact numeric indexes.

3. mmap

Data lives in memory-mapped storage.

The read path doesn't have to constantly perform traditional filesystem I/O.

Conceptually:

disk file
   │
   ▼
 mmap
   │
   ▼
memory address
   │
   ▼
read

This is particularly well suited to read-heavy workloads.

4. Lock-Free Read Path

Writes are a different story.

But reads shouldn't have to wait for other reads.

There is no global:

mu.Lock()
...
mu.Unlock()

on every request.

The hot read path uses atomic reads and direct memory access.

Sharding additionally distributes write contention.

5. JSON Became the Last Enemy

And this is probably the most important conclusion of the entire experiment.

After optimizing the database, indexes, and search, it turned out that the next major problem wasn't retrieving the data.

It was sending it.

That's why moving to a specialized JSON marshaler made such a noticeable difference.

And then something even more interesting became apparent:

>Even when JSON is already as lean as possible, the bytes still have to physically leave the machine.

At that point, no architectural abstraction can help.

The bytes have to move.

Where Is the Real Bottleneck Now?

Very roughly:

request
   │
   ├── routing
   ├── filtering
   ├── index intersection
   ├── sorting
   ├── document lookup
   ├── JSON composition
   │
   └── network output

The first stages have become fast enough that optimizing them further no longer produces the biggest gains.

Now the problem is much more physical:

throughput ≈ available bandwidth / response size

Of course, the real system is more complicated.

But at this scale, that's already the right way to think about it.

If a response is N bytes and the server needs to send tens of thousands of those responses every second, we very quickly stop talking about algorithms.

We start talking about:

how many bytes per second the entire system can move.

And That's Where It Gets Really Funny

You optimize the algorithm.

Then memory.

Then indexes.

Then JSON.

Then unnecessary conversions.

And eventually you discover:

CPU:
    "I can still go."

Makodb:
    "I can still go."

Indexes:
    "We're barely working."

JSON:
    "I've already been put on a diet."

Network stack:
    "Guys..."

PCIe:
    "Slow down."

NIC:
    "Where exactly are you taking all those bytes?"

And this is actually a beautiful stage of optimization.

Because it means you have finally reached the hardware.

What I Took Away from the Experiment

The most important result wasn't 102,339.

It wasn't even 55,632 RPS.

The real conclusion is much simpler:

>High load itself isn't scary. The scary part is how much work you force the system to perform for each request.

If a request requires:

SQL
→ ORM
→ struct
→ reflection
→ map
→ conversion
→ JSON
→ copy
→ socket

then high load quickly turns into a fight against your own architecture.

If the request looks more like:

request
  ↓
index
  ↓
memory
  ↓
bytes
  ↓
socket

then suddenly a single ordinary machine can perform tens of thousands of these operations every second.

And if you remove the response body and leave only the internal processing, you get more than 100,000 requests per second.

Final Numbers

On the current hardware, the experiment demonstrated:

Full GET

≈55,000 RPS

with:

• 5,800 concurrent requests;
• real JSON;
• real business logic;
• filtering;
• sorting;
• index operations;
• 0.0% errors.

HEAD

102,339 RPS

with the same internal request processing and 0.0% errors.

Extreme concurrency

105,800 concurrent requests

without the server crashing and without errors.

Load

Millions of requests per minute.

And after a certain level of concurrency, the system doesn't start dying.

It simply says:

>"I can't go any faster. But I'm not going to fall over either."

And perhaps that's the best result a load test can give you.

Not the biggest number.

But a predictable plateau.

Because a server that turns into a pumpkin when you go from 5,000 to 100,000 concurrent requests is a problem.

A server that says:

>"My ceiling is here. Beyond that, things will simply get slower."

is already a system you can reason about, plan around, and scale.

And that leaves the most interesting question:

If the algorithms are no longer the bottleneck, JSON is already on a diet, and the CPU still has room — how far can we go if the next optimization target is no longer the code, but the path the bytes take from memory all the way to the network interface?

[user nodownload]$ go run main.go -c 5800 -d 60s
[1m0s] Running... shop:2180588 shopCat:1246559 shopSlug:1559589 products:500109 turbo:312322 cats:436086
=== HEAD Load Test Results ===
Duration:   1m0.214s
Concurrency: 5800

GET /shop                 2182135 reqs  36240 req/s  avg=44ms     min=12ms     max=353ms    err=0.0%
GET /shop/{category}      1247457 reqs  20717 req/s  avg=44ms     min=12ms     max=371ms    err=0.0%
GET /shop/{slug}          1561944 reqs  25940 req/s  avg=91ms     min=40ms     max=494ms    err=0.0%
GET /products             500492 reqs  8312 req/s  avg=44ms     min=19ms     max=367ms    err=0.0%
GET /products/turbo       312575 reqs  5191 req/s  avg=44ms     min=16ms     max=313ms    err=0.0%
GET /categories/tree      436449 reqs  7248 req/s  avg=46ms     min=12ms     max=344ms    err=0.0%

Total: 6241052 requests, 0 errors (0.00%), 103648 req/s
[user nodownload]$ cd ../load/
[user load]$ go run main.go -c 5800 -d 60s
[1m0s] Running... shop:1182442 shopCat:675229 shopSlug:843211 products:270361 turbo:169183 cats:236240
=== Load Test Results ===
Duration:   1m0.278s
Concurrency: 5800

GET /shop                 1184095 reqs  19644 req/s  avg=84ms     min=14ms     max=650ms    err=0.0%
GET /shop/{category}      676202 reqs  11218 req/s  avg=86ms     min=17ms     max=649ms    err=0.0%
GET /shop/{slug}          845485 reqs  14026 req/s  avg=163ms    min=83ms     max=877ms    err=0.0%
GET /products             270718 reqs  4491 req/s  avg=80ms     min=18ms     max=547ms    err=0.0%
GET /products/turbo       169429 reqs  2811 req/s  avg=76ms     min=18ms     max=496ms    err=0.0%
GET /categories/tree      236530 reqs  3924 req/s  avg=80ms     min=16ms     max=552ms    err=0.0%

Total: 3382459 requests, 0 errors (0.00%), 56115 req/s

JSON is slow to parse on one hand, but on the other -- it looks like the perfect format for dynamic data.

In this post I'll show what I ended up with when I tried to figure out whether it's possible to speed up data processing at the system level using only Go, combining two things that seem completely incompatible: a high-performance storage engine and the JSON format.

I picked up my virtual scalpel and started cutting away all the abstraction. I don't care about objects. I only care about information.

How It Was Done: Searching for Storage

First things first -- I needed to figure out how to store data on disk without bottlenecking on slow I/O and wasting resources on OS overhead for every read and write. I dug through a ton of options, and honestly, for this kind of task there's nothing better than the "mmap" (Memory-Mapped Files) system call.

The idea is simple: we take the database file and map it directly into the address space of our Go process.

• To the CPU, the entire database looks like one big chunk of memory ("[]byte"). It doesn't even know there's a file on disk behind it.
• When we read data, no system calls like read() happen at all. We just follow a pointer straight into the OS kernel's Page Cache.
• If the page is already in RAM -- the CPU grabs the bytes in ~16 nanoseconds. If it's not -- the OS pulls it from disk in the background, and we don't have to lift a finger.

But Something Was Off: Standard JSON in Go

You'd think "mmap" would solve everything. But the speed was still underwhelming. I started digging -- and it turned out the bottleneck wasn't the disk at all. Go's native module ("encoding/json") can do everything under the sun: convert types, create custom parsers, validate structs. Everything except one thing -- work with information quickly. It parses JSON painfully slow.

That's because the standard parser runs heavy runtime reflection on every single call and creates a pile of objects on the heap for every string and every field.

I couldn't get rid of reflection entirely. But I managed to corner it: it fires exactly once at application startup (Warm-up), and after that it's completely gone from the hot path.

During initialization, we scan the Go struct once with reflection and memorize the memory offsets of all its fields via "reflect.StructField.Offset". We build something like a registry: which field lives at which address.

From that point on, everything flies without reflection:

1. We run through the JSON bytes in a single pass, creating nothing on the heap.

2. Found the right key -- instantly look up its offset in our registry.

3. Pull the value straight from the JSON text and write it to the struct's memory address via "unsafe.Pointer":

   // Write value directly into struct memory at the pre-calculated offset fieldPtr := unsafe.Pointer(uintptr(structStartPtr) + fieldOffset) *(*int)(fieldPtr) = parsedIntVal

That's how lazy parsing was born. If a JSON document has 100 fields but we only need 2 -- the CPU just flies past the other 98. Result: up to 35,000,000 projections per second with zero allocations ("0 B/op").

What Else Does a Proper Storage Need?

Indexes, obviously. Without them any database turns into a dumb brute-force scan of everything.

We have two kinds of indexes:

1. Inverted index for search (keys "idx:<token>" -> array of document IDs in binary form).
2. Sort indexes (keys "sort:<field>" -> ordered array of IDs).

Here I stepped on an interesting rake. When you need to sort 20 million records by some field, the naive approach is to sort the entire array of structs. But each struct weighs ~168 bytes, and on every swap the CPU drags those 168 bytes back and forth. At 20 million records this becomes torture for the CPU cache.

The fix turned out to be simple -- lightweight pairs. Instead of heavy structs, we extract just the ID and the field value into a tiny 16-byte struct:

type SortPairFloat struct {
    ID  int32
    Val float64
} // Just 16 bytes!

16 bytes is exactly what the CPU can shuffle around in its registers without spilling out of the fast L1/L2 caches. Sorting 20 million records dropped from several minutes to ~1.5 seconds.

To avoid recalculating indexes on every write (that would be insane), we went with an LSM-tree approach:

• New documents are appended to the end of the file (append-only, ~500 ns).
• Fresh IDs accumulate in a buffer in RAM.
• On reads, we merge the disk index and the buffer on the fly using two pointers (merge-sort).
• When the buffer fills up (say, 50 items) -- we flush it to disk in a batch using binary search to find insertion points.

How Does JSON Fit Into Data Operations?

Here's the juicy part. JSON is stored in the database as-is -- raw bytes. And that gives us two serious wins:

1. Lazy parsing: need 2 fields out of 100 -- we grab just those, straight from memory, no extra allocations.
2. Zero-copy network delivery: when a client needs the full document over HTTP, we don't parse it and don't encode it back. We just take the byte slice ("[]byte") from "mmap" and write it straight to the socket. The CPU spends exactly zero time on marshalling.

How It All Works Together

+-----------------------------------------------------------------+
|                       Application / BFF                         |
|  [Transaction Buffer in RAM]    [Two-pass Merge Sort]           |
+--------------------------------+--------------------------------+
                                 |
                                 | (mmap / SHM memory mapping)
                                 v
+-----------------------------------------------------------------+
|                       MakoDB Storage                            |
|  Documents (raw JSON bytes):                                    |
|    - "tx:101" -> {"id":101,"country":"Germany","cost":12.5}     |
|  Indexes (binary int32 arrays):                                 |
|    - "sort:cost"           -> [15, 101, 88, ...]                |
|    - "idx:country:germany" -> [4, 101, 502, ...]                |
+-----------------------------------------------------------------+

Key point: indexes are just data, same as the records themselves. You can throw anything into the database and it'll be stored as-is. Indexes live right next to the data under their own prefixes ("idx:" and "sort:") as dense binary arrays.

About Speed

The speed of this system is comparable to reading from RAM. Not from disk -- from actual RAM. Why?

1. No middlemen: we removed network sockets, context switches, protocol parsing. The database is literally part of your application's address space.
2. Page Cache: the OS keeps hot file pages in RAM on its own. We read at memory speed.
3. Zero allocations: Go's garbage collector (GC) stays idle because we create nothing on the heap during queries.
4. CPU cache friendly: data is packed tight and contiguous, the CPU doesn't have to jump around memory.

So, Is It Possible or Not?

Turns out, hell yes. And the results speak for themselves:

• Lock-free reads (Get) in 16 nanoseconds (~60 million requests per second).
• Lazy field projection (Query) in 27 nanoseconds (~35 million requests per second).
• Search and sort across 20,000,000 documents -- under 6 milliseconds!

All of this in pure Go, without third-party code generators, and without heavy runtime reflection.

In this post I'll show what I ended up with when I tried to figure out whether it's possible to speed up data processing at the system level using only Go, combining two things that seem completely incompatible: a high-performance storage engine and the JSON format.

I picked up my virtual scalpel and started cutting away all the abstraction. I don't care about objects. I only care about information.

JSON is slow to parse on one hand, but on the other -- it looks like the perfect format for dynamic data.

In this post I'll show what I ended up with when I tried to figure out whether it's possible to speed up data processing at the system level using only Go, combining two things that seem completely incompatible: a high-performance storage engine and the JSON format.

I picked up my virtual scalpel and started cutting away all the abstraction. I don't care about objects. I only care about information.

How It Was Done: Searching for Storage

First things first -- I needed to figure out how to store data on disk without bottlenecking on slow I/O and wasting resources on OS overhead for every read and write. I dug through a ton of options, and honestly, for this kind of task there's nothing better than the "mmap" (Memory-Mapped Files) system call.

The idea is simple: we take the database file and map it directly into the address space of our Go process.

• To the CPU, the entire database looks like one big chunk of memory ("[]byte"). It doesn't even know there's a file on disk behind it.
• When we read data, no system calls like read() happen at all. We just follow a pointer straight into the OS kernel's Page Cache.
• If the page is already in RAM -- the CPU grabs the bytes in ~16 nanoseconds. If it's not -- the OS pulls it from disk in the background, and we don't have to lift a finger.

But Something Was Off: Standard JSON in Go

You'd think "mmap" would solve everything. But the speed was still underwhelming. I started digging -- and it turned out the bottleneck wasn't the disk at all. Go's native module ("encoding/json") can do everything under the sun: convert types, create custom parsers, validate structs. Everything except one thing -- work with information quickly. It parses JSON painfully slow.

That's because the standard parser runs heavy runtime reflection on every single call and creates a pile of objects on the heap for every string and every field.

I couldn't get rid of reflection entirely. But I managed to corner it: it fires exactly once at application startup (Warm-up), and after that it's completely gone from the hot path.

During initialization, we scan the Go struct once with reflection and memorize the memory offsets of all its fields via "reflect.StructField.Offset". We build something like a registry: which field lives at which address.

From that point on, everything flies without reflection:

1. We run through the JSON bytes in a single pass, creating nothing on the heap.
2. Found the right key -- instantly look up its offset in our registry.
3. Pull the value straight from the JSON text and write it to the struct's memory address via "unsafe.Pointer":

&#8203;

// Write value directly into struct memory at the pre-calculated offset
fieldPtr := unsafe.Pointer(uintptr(structStartPtr) + fieldOffset)
*(*int)(fieldPtr) = parsedIntVal

That's how lazy parsing was born. If a JSON document has 100 fields but we only need 2 -- the CPU just flies past the other 98. Result: up to 35,000,000 projections per second with zero allocations ("0 B/op").

What Else Does a Proper Storage Need?

Indexes, obviously. Without them any database turns into a dumb brute-force scan of everything.

We have two kinds of indexes:

1. Inverted index for search (keys "idx:<token>" -> array of document IDs in binary form).
2. Sort indexes (keys "sort:<field>" -> ordered array of IDs).

Here I stepped on an interesting rake. When you need to sort 20 million records by some field, the naive approach is to sort the entire array of structs. But each struct weighs ~168 bytes, and on every swap the CPU drags those 168 bytes back and forth. At 20 million records this becomes torture for the CPU cache.

The fix turned out to be simple -- lightweight pairs. Instead of heavy structs, we extract just the ID and the field value into a tiny 16-byte struct:

type SortPairFloat struct {
    ID  int32
    Val float64
} // Just 16 bytes!

16 bytes is exactly what the CPU can shuffle around in its registers without spilling out of the fast L1/L2 caches. Sorting 20 million records dropped from several minutes to ~1.5 seconds.

To avoid recalculating indexes on every write (that would be insane), we went with an LSM-tree approach:

• New documents are appended to the end of the file (append-only, ~500 ns).
• Fresh IDs accumulate in a buffer in RAM.
• On reads, we merge the disk index and the buffer on the fly using two pointers (merge-sort).
• When the buffer fills up (say, 50 items) -- we flush it to disk in a batch using binary search to find insertion points.

How Does JSON Fit Into Data Operations?

Here's the juicy part. JSON is stored in the database as-is -- raw bytes. And that gives us two serious wins:

1. Lazy parsing: need 2 fields out of 100 -- we grab just those, straight from memory, no extra allocations.
2. Zero-copy network delivery: when a client needs the full document over HTTP, we don't parse it and don't encode it back. We just take the byte slice ("[]byte") from "mmap" and write it straight to the socket. The CPU spends exactly zero time on marshalling.

How It All Works Together

+-----------------------------------------------------------------+
|                       Application / BFF                         |
|  [Transaction Buffer in RAM]    [Two-pass Merge Sort]           |
+--------------------------------+--------------------------------+
                                 |
                                 | (mmap / SHM memory mapping)
                                 v
+-----------------------------------------------------------------+
|                       MakoDB Storage                            |
|  Documents (raw JSON bytes):                                    |
|    - "tx:101" -> {"id":101,"country":"Germany","cost":12.5}     |
|  Indexes (binary int32 arrays):                                 |
|    - "sort:cost"           -> [15, 101, 88, ...]                |
|    - "idx:country:germany" -> [4, 101, 502, ...]                |
+-----------------------------------------------------------------+

Key point: indexes are just data, same as the records themselves. You can throw anything into the database and it'll be stored as-is. Indexes live right next to the data under their own prefixes ("idx:" and "sort:") as dense binary arrays.

About Speed

The speed of this system is comparable to reading from RAM. Not from disk -- from actual RAM. Why?

1. No middlemen: we removed network sockets, context switches, protocol parsing. The database is literally part of your application's address space.
2. Page Cache: the OS keeps hot file pages in RAM on its own. We read at memory speed.
3. Zero allocations: Go's garbage collector (GC) stays idle because we create nothing on the heap during queries.
4. CPU cache friendly: data is packed tight and contiguous, the CPU doesn't have to jump around memory.

So, Is It Possible or Not?

Turns out, hell yes. And the results speak for themselves:

• Lock-free reads (Get) in 16 nanoseconds (~60 million requests per second).
• Lazy field projection (Query) in 27 nanoseconds (~35 million requests per second).
• Search and sort across 20,000,000 documents -- under 6 milliseconds!

All of this in pure Go, without third-party code generators, and without heavy runtime reflection.

Hello community! We are excited to announce the major update of our JSON parser without code generation and allocations -- silentjson v2.0.0.

First of all, a huge thank you to everyone who supported the project and provided feedback. We wouldn't have come this far without your involvement.

What is new in v2.0.0?

In this release, we focused on ultimate efficiency and specific high-load use cases:

• Scalar parsing optimization (non-AVX2). We have significantly improved the scalar fallback. Now, even on architectures without modern vector instruction support or where they are disabled, the parser shows excellent results.
• hft-ipc. Those who know, know.

The icing on the cake: hitting the physical limits

The main news of the release -- the speed has accelerated so much that we simply stopped being able to catch up. We have practically eliminated software overhead and are now simply hitting the raw hardware and memory bandwidth.

It is cool, yes. But we have to be honest: an extremely heavy load has an impact on us as well. To be fair, in a stress scenario simulation under heavy load, the parsing speed dropped by 60%. But even with this drop, silentjson continues to outperform all competitors by an insurmountable margin. The safety margin turned out to be colossal.

Here is a small teaser with tests on AMD Ryzen 9 7950X3D (parsing 100,000 objects):

Mode	Throughput
Standard (encoding/json)	110 MB/s
Sonic (JIT)	644 MB/s
SilentJSON (Scalar)	810 MB/s
SilentJSON (AVX2)	24 670 MB/s

(Details later or on GitHub)

Do not take our word for it

Do not forget about our contribution and go check if we have deceived you. Just in case.

Update to the latest version:

go get github.com/GenshIv/silentjson@v2.0.0

Post your benchmarks in the comments to this article. Who can do more!

Project Repository: github.com/GenshIv/silentjson

Optimization is always good, of course. But let's be honest: the business needs a product. Here and now. The business rarely thinks about what comes "later". That's why they hire a team of developers and demand features. They need it written faster, shipped faster, and sold faster.

But you don't have to sell just products or features. You can sell solutions.

Imagine a classic scenario: the business has grown, and traffic has skyrocketed (or we started selling 5 times more cupcakes). I had a real case in my practice. They come to me and say: "We urgently need to buy 3 more servers, we can't handle the load". And I look at the metrics and reply: "What for? Our current servers are only at 20% capacity".

Has this ever happened to you? Usually, it's the exact opposite. Developers themselves are begging: "Give us more hardware, our microservices are suffocating".

Now imagine a different dialogue: Business: -- Why did we even buy such an expensive server if it's sitting practically idle right now? You: -- Because the conditions and architecture were different back then. Now, we've made the code run efficiently.

Do you know what the main problem is? The business buys "features", even though it actually wants to buy a solution. But very few people actually sell those solutions. Most often, developers just sell "delayed headaches" with the condition of buying new hardware and endlessly scaling horizontally.

It's hard to blame the programmers here. We all live in a certain engineering culture where abstractions take center stage, and understanding how the hardware actually works is considered "low-level" and unnecessary. Let's look at how we got here through three famous quotes.

>"Software is getting slower more rapidly than hardware becomes faster." -- Niklaus Wirth, creator of Pascal (Wirth's Law, 1995).

In the race for development speed, we started hiding the hardware behind thick layers of frameworks, virtual machines, and Garbage Collectors. We are "burning" all the massive computing power that modern multi-core processors give us just to maintain these abstractions. Hardware gets more powerful every year, but programs run slower and slower for the end user.

>"We broke monoliths into microservices to solve management problems, not performance problems." -- Kelsey Hightower, one of the main evangelists of Kubernetes.

Many young developers believe that microservices are synonymous with HighLoad and speed. In reality, we took a lightning-fast local memory call (which took nanoseconds) and replaced it with a slow network request with endless JSON serialization (which takes milliseconds). The industry voluntarily traded pure CPU speed for insane network latency.

And finally, we got way too carried away with trendy design patterns:

>"I made up the term ‘object-oriented’, and I can tell you I did not have C++ in mind." -- Alan Kay, one of the creators of Smalltalk (OOPSLA '97).

A bit later, he added:

>"I’m sorry that I long ago coined the term “objects” for this topic... The big idea is messaging."

We somehow unnoticeably got carried away with beautiful objects, abstract factories, and layers, completely forgetting how the system actually communicates internally and how this code will eventually be executed in silicon.

But there is another way. We can "sell" servers to the business without physically selling them. Even servers that haven't been bought yet!

The point is, if you deeply study your domain, you can strip away all the architectural fluff. You can implement your idea so that it eats microscopic CPU ticks, rather than entire server racks. Essentially accelerating the system and reducing resource consumption not just by a factor of ten, but by hundreds of times.

Engineering is when your code works in synergy with the processor, not fights against it.

Join our community at r/HiLoad. Let's find elegant solutions, not just "ship features".

And now, a question for you: How often have you managed to convince the business when they asked to "just buy more hardware", instead of giving you time to find and optimize the bottleneck in the architecture? Share your stories!

Hey r/HiLoad,

I wanted to share a war story from a past project. We were dealing with a classic nightmare: receiving millions of products from suppliers and having to classify them instantly as their price lists came in.

Because it was the trendy thing to do, we initially threw a neural network at the problem. In production, it was actually pretty snappy. But the training phase? An absolute dumpster fire. The human factor completely ruined it because the team responsible for managing the catalog and keywords was frankly just phoning it in.

They kept feeding absolute garbage into the training set. Naturally, the model choked on this chaos and started hallucinating wildly. My personal favorite was when it confidently classified a massive batch of toilet paper into the "Baby Car Seats" category. You can imagine the collective groan from the dev team when we had to stay up half the night manually unscrewing thousands of misclassified items after a "successful" release.

To make it all worse, retraining this beast took up to two weeks. And the punchline? Because the catalog team never stopped making mistakes, we had to kick off this miserable two-week process almost every single month. Two weeks of training, maybe two weeks of peace, then someone uploads garbage again, paper towels suddenly belong in Auto Parts, and we're back in hell.

We desperately needed a solution that was dead-simple, rock-solid, easy to debug, and -- most importantly -- didn't need two weeks to learn what a car seat is. The fix turned out to be surprisingly elegant: we ripped out the ML magic entirely and replaced it with pure math.

From Words to Numbers: The Magic of Overflow

The core idea was to turn any product description into a tiny, numerical "fingerprint."

The pipeline was stupidly simple:

1. Take the raw product name.
2. Strip out all the garbage (stop words, prepositions).
3. Run it through a stemmer to just get the root words.
4. Hash each meaningful root into an int64.

Here’s the fun part. We didn't store an array of hashes. We just added them all together using standard binary addition. The trick here is that when you add large numbers in int64, you get a natural overflow, which just drops the most significant bits. In Go (and C/C++), this is completely legal, costs zero CPU cycles, and happens instantly.

The code looks almost too simple:

import "hash/fnv"

// Hash a single cleaned root word
func hashWord(word string) int64 {
	h := fnv.New64a()
	h.Write([]byte(word))
	return int64(h.Sum64())
}

// Get the numerical fingerprint for the whole product name
func getProductFingerprint(tokens []string) (hashSum int64, wordCount int) {
	for _, token := range tokens {
		// Stop-word filtering and stemming happens around here
		if isStopWord(token) {
			continue
		}
		
		wordHash := hashWord(token)
		
		// Standard binary addition. 
		// The int64 overflows naturally—no panics, no worries.
		hashSum += wordHash 
		wordCount++
	}

	return hashSum, wordCount
}

Just like that, we packed the "meaning" of an entire product name into exactly one int64 -- regardless of whether it had three words or ten. We'd also generate a few of these fingerprints per product to cover permutations and weird supplier spellings.

The Index and Foolproofing

That int64 became our key. For lookups, we just threw it into a standard in-memory Map. The value was a tiny struct:

1. ID of the target category or product model.
2. Word Count -- the exact number of tokens that built this hash (that wordCount variable from the code).

Why keep the word count? That was our bulletproof vest against collisions and our secret weapon for smart ranking.

When a new item came in from a price list, we'd run its name through the pipeline and hit the Map. If the int64 matched, we absolutely had to check if the word counts matched too. This took the chance of a false collision (two different sets of words accidentally summing to the same hash) down to mathematical zero.

During a lookup, we'd generate fingerprints for various combinations of words in the name. If we got multiple hits, the category that matched the highest number of words won. Longer phrase = more accurate match.

Trust, but Verify (The Dev-Tool)

Given our PTSD from the catalog team (never forget the toilet paper car seats), we refused to do any more blind debugging. If an item went to the wrong category, we wanted receipts.

So, we built an internal Dev-Tool. You paste a product name in, and it spits out the exact thought process: how it was tokenized, the stemmed roots, the int64 hashes, and crucially -- which exact words matched the database and which were ignored.

You can't argue with transparent math. Whenever someone complained about a misclassification, we could find the culprit (usually a horribly written keyword rule) in two clicks, rather than spending hours trying to decipher neural network logs.

Performance

The numbers were great. Even with 5 million unique products (which balloons to tens of millions of records when you add the hash variations), the whole index (int64 Key + Category ID + Word Count) barely took up a couple hundred megabytes.

The entire thing lived comfortably in RAM. Classifying a single item meant a couple of fast hashes and an O(1) map lookup. We were chewing through incoming price lists at the speed of the network interface while the CPU basically sat there twiddling its thumbs.

Scaling it out

Since it was just a Map, it scaled horizontally like a dream. We just distributed the heavy price list streams across worker goroutines. No DB transactions, no table locks, no massive SQL queries -- just pure arithmetic and memory reads.

We also reused this for validation. If a supplier sent a product and its fingerprint matched a model we already knew, the system instantly recognized it as a duplicate. We just attached the new price to the existing item and kept the catalog completely clean.

TL;DR: ML isn't always the answer. Sometimes, adding a bunch of hashes together and letting the integer naturally overflow gives you an instantly searchable, O(1) in-memory index that takes up almost no RAM and doesn't take two weeks to train.

Curious to hear from you guys -- how would you handle cache invalidation for an in-memory setup like this if the business decides to change the stop-word dictionary or stemming rules on the fly? Would love to hear your thoughts.

If you’ve ever spent days hunting down a memory leak, fought the Garbage Collector in production, or rewritten a perfectly readable function into an ugly, unsafe assembly kernel just to squeeze out an extra 500 MB/s of throughput — welcome home.

I created r/HiLoad because I felt something was missing in the standard programming subreddits. Too often, deep technical posts about performance optimization or niche architectural choices are met with "just use the standard library," or worse, removed by moderators for "self-promotion."

Here, the rules are simple and built for engineers:

1. Performance over purity We respect beautiful code, but we respect production metrics more.

2. Bring the receipts (Data & Benchmarks) We love flame graphs, allocation metrics, and throughput numbers. We love data.

3. Show and Tell (Yes, you can share your projects!) If you built a crazy fast tool, library, or pipeline — share it! Self-promotion is absolutely allowed and encouraged here, as long as you provide technical context. Tell us the problem, how you solved it, the tradeoffs you made, and what didn't work.

What to post:

• Deep dives into backend architecture at scale.
• Optimizing CPU, Memory, or I/O.
• Database scaling and query tuning.
• "War stories" from production outages and how you fixed them.
• Benchmarks and performance comparisons of languages/frameworks.

Make yourself at home. Drop a comment, share what you're currently working on (or struggling with), and let's build a community that actually cares about how things run under the hood.

I had a real problem at work: we were constantly processing massive JSON array dumps — catalogs, analytics exports, ML datasets. The files ranged from hundreds of megabytes to tens of gigabytes.

The task was simple: split a giant JSON array into individual objects so they could be routed, chunked, or processed in parallel. That's it. No transformation, no querying by field name — just find where each {...} starts and ends.

And yet, we were doing json.Unmarshal → slice → json.Marshal. On a 10 GB file, the memory usage was absurd, and we spent more time fighting the GC than doing actual work.

At some point I realized: we don't need to understand the data to move it. We just need to find the boundaries.

The idea: boundary extraction

Instead of building an object tree (which is what every parser does — even fast ones like simdjson or sonic), you can treat JSON as a byte stream with structural markers and just scan for the edges of each object.

The logic boils down to a small state machine:

1. Nesting counter: { increments, } decrements.
2. String tracking: you need to know if you're inside "..." so you don't count braces inside string values.
3. Escape handling: a \" inside a string is not a real quote.
4. The boundary: when the nesting counter returns to 0 after being >0, you've found one complete object.

That's it. You don't look at keys. You don't look at values. You don't allocate anything. You return slices (memory views) into the original buffer.

Here's the conceptual core in Go (simplified, without the string-tracking):

gofunc findBoundaries(data []byte) []Chunk {
    var chunks []Chunk
    depth := 0
    start := -1
    for i, b := range data {
        switch b {
        case '{':
            if depth == 0 {
                start = i
            }
            depth++
        case '}':
            depth--
            if depth == 0 && start >= 0 {
                chunks = append(chunks, Chunk{Start: start, End: i + 1})
                start = -1
            }
        }
    }
    return chunks
}

Of course, this naive version is wrong — it doesn't handle strings, escapes, or nested arrays. But the principle is the key insight: you're not parsing, you're scanning.

Why this is fast

When you scan boundaries instead of parsing:

• Zero allocations in the hot path. You return data[start:end] — a slice of the original buffer. No new objects, no string copies, no map construction.
• Cache-friendly. Your working state is a couple of integers (depth counter, string flag). Everything fits in L1. The only memory access pattern is a linear sequential read.
• Pipeline-friendly. A state machine with predictable transitions is much kinder to the CPU's branch predictor than a parser that dispatches on dozens of token types.

Compare this to what a "real" parser does:

Step	Full parser	Boundary scanner
Read bytes	✅	✅
Classify tokens	✅	Only {}[]"\
Build hash maps	✅	❌
Allocate strings	✅	❌
Allocate slices	✅	❌
Type conversion	✅	❌
Return objects	[]MyStruct	[][]byte (slices into original buffer)

You're literally removing 80% of the work.

But how fast, really?

I got curious and decided to implement this properly — with a real string-aware state machine, correct escape handling, and a full AVX2 assembly kernel on amd64 for the hot scanning loop (processing 32 bytes per cycle, using SIMD bitmasks to classify structural characters in parallel).

Honestly, the results surprised even me:

Approach	What it does	Throughput	Memory overhead
encoding/json Unmarshal	Full parse → Go structs	~107 MB/s	3-4x input size
sonic / simdjson-go	Optimized parse → structs/AST	~400–700 MB/s	~1.1x
Boundary scan (AVX2 asm)	Just finds {...} edges	~4.1 GB/s	~1.0x (zero extra)

>

The ~4.1 GB/s number is essentially limited by memory read bandwidth on my machine, not by the scanner's logic. The AVX2 kernel spends most of its time waiting for the next cache line to arrive.

When this is (and isn't) useful

Good fit:

• Splitting a huge JSON array into files/chunks for parallel processing
• Streaming: extracting objects from an io.Reader on-the-fly without loading the whole thing into RAM
• Proxying/routing: forwarding individual JSON objects from an array to different consumers
• Pre-processing for a real parser: find boundaries first, then parse each chunk on a separate goroutine

Bad fit:

• You need actual field values (you'll need a parser anyway)
• Your JSON isn't arrays-of-objects (this technique targets [{...},{...},...])
• Small files where the overhead of json.Unmarshal is negligible

The tradeoffs

Since I went the unsafe / raw assembly route for maximum performance, there are real costs:

• Platform-specific. The AVX2 path only works on amd64. You need a scalar fallback for ARM/other architectures.
• unsafe usage. Any time you avoid allocations by returning slices into a shared buffer, you need to be very careful about the buffer's lifetime. If the underlying []byte gets overwritten or GC'd while you still hold slices — boom.
• Not a validator. The scanner trusts that the input is valid JSON. It won't give you nice error messages about malformed data.

Closing thought

The mental shift was surprisingly simple: stop thinking "I need to parse this JSON" and start thinking "I need to find the boundaries in this byte stream." Once you reframe the problem, the solution practically writes itself — and the performance gap compared to full parsing is enormous.

Has anyone else gone down this path? I'm curious how people handle large-scale JSON splitting/routing in production — especially the streaming case where you can't load the full file.