sh4.tech
Luciano Serra
Luciano Serra Founder-engineer · co-founder & CTO, built a 15,000-screen network from zero, 2015–2024 · São Paulo, remote Email LinkedIn Résumé (PDF)

Systems that hold up when the business grows.

Twenty years shipping software. I co-founded a digital out-of-home media company in Brazil and built its technology from zero: the first screen to 15,000, 200 million proof-of-play events a day, 300 billion rows in self-managed ClickHouse. My partners raised the money and ran sales, and I built and ran the technology for ten years.

I design production systems from zero, and I take over the ones already running. Both have to hold up when the business grows.

Your business is growing faster than your systems? Let's talk → Read the articles ↓

now ▸ building from zero a performance platform for professional athletes, for a sports-science company in London. Python, FastAPI, Next.js; 300,000+ data points pulled from a vendor portal that has no API, and the AI insights engine comes next.

Orders of magnitude, from production log₁₀ of a count · 10³ to 10¹²
  1. 15,000screens in the field
  2. 5,392,734machine-days in 2026
  3. 200Mproof-of-play events per day
  4. 100B+rows in the largest table
  5. 300B+rows stored

Five different things counted on one axis. The axis only says how many; each mark says what it counts.

How I work, from zero or from what already runs

Measure. Build or fix. Then grow the business on it.

In that order, because each step gives the next one its numbers. The same order for a product that has to exist by a date and for one that already runs and has to stop breaking.

  1. Measure

    First I find the number the business has to trust: counts at the source, counts at the destination, and the difference between the two. If nothing exists yet, the first version is designed around that number. It takes a few days to get it, and usually the conversation already changes there.

  2. Build, or stabilize

    From zero: the smallest system that produces that number right, with the path to scale already drawn, because rewriting under load is the expensive version. Already running: make it stop breaking. Duplicates, timeouts that hide each other, jobs alive only because deploys restart them. Same input gives the same output every day, and anyone can check it.

  3. Grow

    Then the business grows on it: more screens, more clients, more rows, without a rewrite. Sort keys before codecs, retention by data type, batches instead of chatty protocols. Each decision is made with the numbers from step one, so it can be checked against them later.

Built it fast with AI? Good. AI gets you to the demo. I get it to production.

Luciano Serra leaning on a chair by an office window
São Paulo · UTC−3
Articles

Answers to the question you searched for, with the numbers attached.

Tip1 to 3 min Note3 to 6 min Deep dive8 min and up
All articles, by problem →
Cases

One built from zero. Two taken over running. All three measured.

Production systems with revenue depending on them being right. Names of clients and partners left out on purpose; the numbers are the ones we measured.

All cases →

Built from zero

300B+rows

327.43 billion rows in 2.08 TiB, the largest table 100.78 billion · 2026-09-03

The proof-of-play platform behind 15,000 screens

Designed
One row per ad play, as billing evidence, from screens that lose the network for hours. Playlogs cached on the device, uploaded in batches to an ingestion server, then Kafka into self-managed ClickHouse. MQTT only for presence and telemetry.
As it grew
Two billion rows in MySQL stopped being reasonable, so the store moved to ClickHouse on bare metal. Sort key chosen for the queries first, then one codec pair per column profile, tested over about sixty variations with the heaviest query in the loop.
Running
200 million rows a day for years. 5.5x overall, 269.6x on the sort-key timestamp, 4.37 bytes per row. The fleet went from the first screen to 15,000 on the same design.

clickhousekafkaedge buffering

Taken over running

460,691

machine-days validated against the source, 18 differences · Oct 2026

Reconciling what was sold with what was on air

As found
Three occupancy engines in the codebase, each with its own idea of a machine-day. Sales wanted a screen; the number behind it couldn't be trusted.
Changed
Merged the engines into one before building anything visible. The screen reads a precomputed snapshot and flags sold-versus-aired divergences. A full month was validated line by line against the source.
Held
5,392,734 machine-days for 2026, finance matched 100%, and the commercial director compared it to cataract surgery and made it the team's daily routine. Commercial decisions now start from this screen.

reconciliationsnapshotaudit

Taken over running

−67%

telemetry messages per day after the switch · measured on the topic, 2026

Moving device presence to MQTT without losing the fleet

As found
15,000 screens in elevators and malls announcing themselves over HTTP polling. Losing contact with a screen in the field was the one thing we couldn't afford.
Changed
Four months of testing and a controlled rollout. I set the direction and reviewed every step; a teammate did most of the hands-on work. Proof-of-play kept its own path: cached on the device, uploaded in batches, then Kafka into ClickHouse.
Held
Telemetry volume on Kafka dropped by two thirds with the same fleet, and the billing path stayed exactly as it was.

mqttfleetrollout

About

Co-founder, engineer, operator. I built the technology; my partners raised the money and ran sales.

I co-founded a digital out-of-home media company in Brazil and built its technology from zero, from the first screen to a fleet of 15,000. Building the technology and also raising capital and running sales is more than one person's day, so we split the work: I built and ran the technology for ten years, my partners took care of capital and sales. I was always close to the business side anyway; the occupancy screen in the cases above is where the commercial team starts the morning.

Today I still lead technology projects there, and I am building from zero a performance platform for professional athletes for a sports-science company in London: Python and FastAPI, Next.js, 300,000+ data points pulled from a vendor portal that has no API; the AI insights engine is the next part.

I grew up in the Brazilian racing paddock, where my father is a legend. My habit of measuring everything comes from there, and also the respect for things that can't fail on race day. I also train jiu-jitsu.

sh4 means nothing. It's short and easy to remember, that's all.

The longer version →

  • 15,000screens in the field, elevators and mallsfleet size at the time of measurement, rounded
  • 200Mproof-of-play events a day, Kafka into ClickHouse~196.7M rows/day, sum of the four log tables, 2026-09-05
  • 300B+rows kept, the largest table past 100 billion327.43B rows in 2.08 TiB, 2026-09-03

Growing faster than your systems?

Let's talk → LinkedIn

Two ways this usually starts. A business with revenue that has to grow without breaking. Or a product that works in the demo and breaks in production. Write me which one. I answer with questions, then with a plan.