DEV Community: Carl-Gerhard Lindesvärd

How Queues Saved Our API from Meltdown

Carl-Gerhard Lindesvärd — Mon, 08 Dec 2025 19:58:02 +0000

Most developers don't think about queues until the day their API catches fire. You build an endpoint, it works fine, then someone sends a spike of traffic and suddenly everything slows down. Requests hang, CPU spikes, retries add even more load. It turns into chaos really fast.

This was us at OpenPanel. Our ingestion endpoint handles a lot of traffic. It grew slowly at first, then a few customers started sending big bursts and everything fell apart. Not gradually. It went from perfectly fine to completely overwhelmed in minutes. We didn't scale the API. We offloaded it.

Queues are not over-engineering

People like to say queues are only for giant enterprise systems. I don't really buy that. A queue is basically an async function that runs later instead of right now. That's all it is. You don't need microservices or some huge distributed setup to use one. You just need a spot where you push work so your API doesn't do everything inside the request lifecycle. It is simple, and it can completely change how your system behaves under load.

When queues actually help

There are a lot of good use cases, but these are the clearest ones.

Heavy background tasks. Sending emails, notifications, PDF generation. Any slow thing the user doesn't need to wait for.

Recurring jobs. Queues are a great way to run cron logic inside your own code instead of managing some external service. You get more control over retries and timing.

Better user experience. This one feels small but it is amazing in practice. Imagine a user writes a comment. Without a queue you would save the comment, then check who needs a notification, then send every single one. The user sits there waiting for all of this to finish. With a queue you save the comment and push a job. The API returns right away. Notifications get sent in the background. Huge UX win for basically no effort.

Ingestion endpoints. This is the big one for us. Our tracking endpoint used to validate events, transform them, fetch extra data, and insert everything. All inside one request. That works until someone sends 20 times the normal traffic. Then it stops working pretty fast.

Now the endpoint does one thing. It pushes the event into a queue and returns. Done. The user only cares that we received the request. They do not care what we do after that. This change made the whole ingestion layer stable even when we get huge spikes. If the workers fall behind it just means a delay. We do not lose data. The API stays fast. The queue absorbs the blow instead of the server falling over.

A simple BullMQ example

Here is a bare bones setup you can add to any Node API.

import { Queue, Worker } from 'bullmq'
import Redis from 'ioredis'
import http from 'http'

const redis = new Redis()
const queue = new Queue('jobs', { connection: redis })

http.createServer(async (req, res) => {
  if (req.url === '/track' && req.method === 'POST') {
    const body = await readBody(req)
    await queue.add('track', body)
    res.writeHead(200)
    res.end('ok')
    return
  }

  res.writeHead(404)
  res.end()
}).listen(3000)

new Worker('jobs', async job => {
  await processEvent(job.data)
}, { connection: redis })

You can even run the worker in the same process while prototyping. When you go to production you normally split them.

Using queues in a serverless world

Serverless makes this trickier because you can't keep workers alive. But there are solutions.

Trigger.dev gives you background jobs and retries without needing long running processes. It works with a bunch of runtimes and solves the exact problem that queues solve for traditional servers.

Vercel's Workflow API is also interesting. You write background workflows as simple functions. They run outside the request flow and persist on their own. If you are already using Vercel this feels like cheating. You get a lot of the benefits of a queue without running Redis or workers yourself.

Why queues mattered for us

Before we added queues, any traffic spike would make our ingestion API slow or unstable. After we added queues it became boring. And boring is exactly what you want in production.

Queues let us keep the API tiny and predictable. Workers do the heavy work. Traffic spikes turn into a backlog instead of downtime. This one change made OpenPanel a lot more reliable for everyone using it.

A quick note about OpenPanel

Queues have become a core part of how we keep OpenPanel fast. Our ingestion API gets a lot of traffic every day and queues turned it from something fragile into something we don't need to think about anymore. We use them for event ingestion, cron tasks, cleanup jobs, and anything that should not block the user. It is one of the reasons OpenPanel can handle heavy load without falling over.

If you want an open source analytics platform that can survive traffic without feeling fragile, take a look at it. It is fully self hosted and built for real world workloads.

In the next article I will talk about GroupMQ, our custom built queue library. It is a drop in alternative to BullMQ with first class support for grouped queues and ordered processing. These features saved us more than once, and I think a lot of teams will find them useful.

ClickHouse: The Good, The Bad, and The Ugly

Carl-Gerhard Lindesvärd — Mon, 17 Nov 2025 15:02:11 +0000

ClickHouse is one of those databases that everyone gets excited about after their first benchmark. It’s absurdly fast, column-oriented, and built for analytics at scale.

It’s also surprisingly easy to plug into an existing stack. You can stream data from Postgres, Mongo, S3, or pretty much anywhere. That’s what makes it so appealing. You hit the point where your Postgres queries start to struggle, you don’t want to rebuild everything, so you drop in ClickHouse and suddenly your dashboard loads in milliseconds.

It’s like putting a turbocharger on your reporting.

ClickHouse is also improving at a crazy pace. Every month they roll out new features, bug fixes and faster queries.

But with speed comes responsibility. ClickHouse is a beast. It’ll reward you when you treat it well, but it’ll bite you if you cut corners.

Cloud vs self-hosting

Your first big decision is whether to self-host or go with a managed provider.

	Cloud	Self-Hosted
Setup time	Minutes	Days/weeks
Cost at scale	$$$	$ + engineer time
Backup/HA	Automatic	DIY
Headaches	A few but not hosting related	Many
Good for	Most use cases	Cost optimization

The cloud route is painless. You get uptime, automatic scaling, and zero headaches. The trade-off is cost. ClickHouse Cloud, Altinity Cloud, Tinybird, they all work great, but the bill can sting hard once you start pushing data around. You don’t get server issues, but you pay for the peace of mind.

In Clickhouse Cloud you also don't need to worry about replication, this is handled under the hood so you don't need to create replicated and distributed tables.

Self-hosting looks easy at first, but it’s not.

You spin up a single node, everything flies, and then one day something fails, stops merging data, corrupt data or what ever. This is just the top of the iceberg.

To handle real production traffic you’ll end up with replicated and distributed tables. You’ll need to decide between vertical scaling, horizontal scaling, or both. Then you start worrying about corrupted parts, cluster topology, and backups.

Running ClickHouse yourself works fine for smaller setups. Once you grow, it’s a full-time job unless you use something like the Altinity ClickHouse Operator on Kubernetes. That operator makes things bearable. You define clusters in YAML, it handles replication, zookeeper (Clickhouse Keeper), and have great backup strategies. If you ever plan to self-host long-term, start there.

The dark side of joins

Joins in ClickHouse are not the joins you’re used to. They work, but they’re not “free.”

ClickHouse doesn’t have a full query optimizer like Postgres or MySQL. That means it doesn’t plan your joins intelligently. If you join two big tables, it’ll happily try and load everything in memory and die trying.

You have to think ahead. Filter first, join later.

A few ways to survive:

Use CTEs or sub-queries to narrow down the joined dataset before the join actually happens.
Use dictionaries (in-memory lookup tables) for small reference data. They’re insanely fast, but they have to fit in memory.
Know your sorting keys. ClickHouse relies on them for efficient reads. Bad keys make joins worse.
Always join the smaller table

You'll notice when you have a bad join since it will take ages or die trying.

Updates, deletes, and the reality of immutability

ClickHouse was never designed for frequent updates or deletes. It’s a write-once, append-forever kind of database. You can’t just run UPDATE users SET ... like in Postgres.

To their credit, the ClickHouse team has made big progress here. They’ve added lightweight deletes and updates, and there are new table engines like ReplacingMergeTree and VersionedCollapsingMergeTree that can simulate mutable data. But it still takes extra thought.

You need to design your tables knowing that changing data later is harder. That’s fine for analytics workloads, but painful if you expect relational behavior.

I still run into these kind of issues today. Hoping the lightweight updates which is in beta now will make my life easier.

Inserting data the right way

Here’s the biggest beginner trap.

ClickHouse loves big inserts. It hates small ones.

Every insert triggers background merges, index updates, compression, and part creation. Do that one row at a time and you’ll drown it. Batch your inserts into chunks, ideally thousands of rows at a time. You’ll instantly see CPU drop and throughput skyrocket.

If you’re ingesting data continuously, throw it into a queue and batch it there. That’s what we do at OpenPanel.dev. It smooths out traffic spikes and keeps our ingestion fast and predictable.

Replication and sharding

This isn’t a bad thing about ClickHouse. In fact, it’s one of its best features.
But I still want to cover a few parts that confused me when I first started using it.

There are three kinds of tables you’ll deal with when setting up replication or sharding:

Your existing table (usually MergeTree or something similar)
A replicated table (ReplicatedMergeTree)
A distributed table (Distributed)

Each of these plays a different role in your cluster, and it’s worth understanding them before you begin.

First, decide how many replicas you want. Most setups use three replicas for high availability and to get replication working, you’ll replace your existing table with a replicated one.

You can do that by creating a new table and swapping MergeTree for ReplicatedMergeTree in the engine section.

CREATE TABLE events_replicated ON CLUSTER '{cluster}' (
  ...
)
ENGINE = ReplicatedMergeTree(
  '/clickhouse/{installation}/{cluster}/tables/{shard}/openpanel/v1/{table}',
  '{replica}'
)
PARTITION BY toYYYYMM(created_at)
ORDER BY (created_at)

Once that’s done, any data written to one node will be replicated to the others. ZooKeeper or ClickHouse Keeper handles the synchronization automatically.

If you want to move your data from your existing table to the replicated table you can use INSERT SELECT to do this.

INSERT INTO events_replicated SELECT * FROM events;

Now let’s look at where sharding and Distributed tables come in.
Sharding is how you scale horizontally by splitting data into smaller chunks and spreading them across nodes. That said, it’s usually better to scale vertically first, because ClickHouse handles vertical scaling surprisingly well.

If you decide to shard, you’ll need to create a distributed table. A distributed table knows where your data lives and redirects queries to the right node.

When creating one, you define how data should be split across nodes. In the example below, the data is sharded using cityHash64(project_id), which spreads rows evenly based on the project_id.

CREATE TABLE events_distributed ON CLUSTER '{cluster}' AS events_replicated
ENGINE = Distributed(
  '{cluster}',
  currentDatabase(),
  events_replicated,
  cityHash64(project_id)
)

Now you can query data from any node, and ClickHouse will automatically route the request to where the data actually sits.

If you want to dig deeper, check out the official docs on Distributed tables and Replication.

So why stick with it?

Because when it works, it’s magic.

At OpenPanel we hit all these issues. Slow inserts, bad joins, tricky replication, and we still use ClickHouse every single day. Once you set it up correctly, nothing else compares. It’s unbelievably fast and scales far beyond what most relational databases can handle.

You just have to respect it. Treat it like a Ferrari, not a Corolla.

If you want me to go deeper into how we deploy and manage our own cluster on Kubernetes using the Altinity operator, let me know in the comments. I can show exactly how we keep it stable and cost-efficient.

How I Accidentally Built My Own Mixpanel Alternative

Carl-Gerhard Lindesvärd — Tue, 11 Nov 2025 14:38:01 +0000

Two years ago, around September 2023, I was working on one of my side projects. It wasn’t making money, but I wanted to understand how people were using it, so I used Mixpanel.

At first it was fine. We were part of Mixpanel’s startup program, which made it free to use. That app had maybe 250–500k events a month, not much. Then the program ended. Suddenly the bill jumped to $300–400 a month.

That was a bit painful for a project that had 10k active users a month

Why I didn’t just switch tools

I looked around. PostHog looked great, but it felt too advanced and heavy for what I needed. Plausible and Umami were cool for web analytics, but they didn’t support real product analytics, and custom events were behind enterprise plans.

What I really wanted was something in between.

The simplicity of Plausible.
The depth of Mixpanel.
And the freedom of open source.

That combination didn’t exist.

The moment it clicked

One evening I pulled data from my Postgres database and made a small chart just for fun.
When I saw that chart update with live data, I realized I could actually build the kind of reporting tool Mixpanel had.

That was the moment OpenPanel started.

I figured if I was already logging events, why not build something that gives me full control? At first it was just an experiment. But after a while, I saw the bigger picture. If I wanted proper product analytics, I’d also need to track web data. So I started combining the two.

Product analytics plus web analytics in one self-hosted stack.

The early stack

The first version was a mix of Next.js, Node, and Postgres. It wasn’t fancy, but it worked. I could track events, view them, and draw basic charts.

Postgres handled things fine until the event count grew. Once it hit millions, queries started slowing down. That’s when I moved to ClickHouse and kept Postgres for application data.

It was the first time OpenPanel started to feel like a real analytics product.

The hard parts

I’ve honestly given up on this project at least a hundred times.

Building an open source platform that handles real data is hard. You fight with performance, storage, schemas, queues, and migrations. Every change has ripple effects.

And then there’s the self-hosting part. You can’t just ship code. You have to think about Docker setups, upgrade paths, environment variables, and all the edge cases that don’t show up in your own environment.

It’s a lot. But every time I get a message from someone who deployed it successfully or a paying customer saying “this saved us thousands,” it’s worth it. That feeling keeps me going.

How it’s going now

Fast forward to today — OpenPanel handles around 100 million events per month and around 200 self-hosted instance (what we know about).

Some of our bigger customers have actually moved to self-hosting to save costs, which is exactly what I wanted. Open source analytics should give you control and options, not lock you in.

The product has come a long way since that first chart I created.

It’s now a complete analytics suite that combines product analytics and web analytics in one place, with no cookies, no user tracking, and full self-hosting support.

You can think of it as a Mixpanel alternative that’s simple like Plausible but powerful enough for real apps.

Why I’m still building it

OpenPanel started as a personal project because I couldn’t find what I wanted. Now it’s turning into something bigger.

The goal hasn’t changed though. I want to make analytics tools that are simple, transparent, and don’t punish you for growing.

If you’ve ever been frustrated by pricing tiers, missing features, or vendor lock-in, you’ll get it.

That’s why I built OpenPanel, mainly for myself but now its available for anyone. Want to find out more, visit our website https://openpanel.dev

Why We Ditched Next.js for TanStack Start

Carl-Gerhard Lindesvärd — Thu, 06 Nov 2025 14:10:25 +0000

I run OpenPanel.dev, an open source, privacy friendly analytics tool. So our own dashboard kind of has to feel fast. If your analytics app is slow, nobody will use it.

For a long time that dashboard ran on Next.js. I have used Next since the early days. It made SSR feel easy. You wrote some React, added getServerSideProps, shipped it, and it worked. No deep framework knowledge needed.

That version of Next was nice.

Then the App Router arrived. Then React Server Components. And everything started to feel... wrong.

How Next.js went from "nice" to "what is going on"

The idea behind RSC is clever. In practice it turned our app into a puzzle.

You get:

components that are secretly server only or client only
promises and Suspense sprinkled in places that are hard to follow
caching that acts differently depending on which file you put the code in
middleware.ts that does not really behave like middleware in the classic sense

The old "just works" feeling was gone. Every bug felt like a framework behavior you had not learned yet.

On top of that, Next.js became the default choice in the React world. Every big voice on X talks about it, tutorials use it by default, companies hire for it. So you feel a bit stupid even for questioning it.

But here is the problem. Nobody asks a basic question.

What kind of app are you building?

If you are building a marketing site or a mostly static e-commerce store, Next.js is amazing. SEO, images, static pages, all good.

If you are building an interactive website, that is different. You want instant navigation, predictable state, and simple data loading. Instead you get server round trips on every navigation, cache layers that act like a black box, and stack traces that go from client to server to client again.

It is not that Next.js is broken. It is just overloaded with ideas that look great in a conference talk but hurt once you have real users.

What hurt in practice at OpenPanel

Here is what it felt like day to day while building OpenPanel on Next 14.

1. Navigation was slow

Switching between pages in the dashboard felt heavier than it should. Even with prefetching. You could feel the server in every click.

2. Caching bugs out of nowhere

When you fetch data inside an RSC, Next.js decides when it should be revalidated. Sometimes it updates right away. Sometimes it doesn’t. You start throwing revalidatePath or no-store everywhere just to make it behave.

Half the time we couldn’t even tell what was cached. Was it our fetch call? Or the framework holding on to something behind the scenes?

That might be fine for a static site, but not for a live analytics dashboard...

3. Development was painful

Dev server startup: 25 to 30 seconds.
Change route: wait a few seconds for the compiler. Repeat. All day.

You want to tweak a chart, hit save, see it instantly. Instead you get to watch the progress bar and think about your life choices.

4. It felt like we were tied to Vercel

Yes, you can self host Next. I know. But the whole thing is clearly designed with Vercel in mind. The DX, the docs, the examples. It all nudges you in that direction.

We run on Hetzner and lean heavily into the self hosted story, so that feeling of "this framework really wants you on Vercel" did not sit well.

At some point we realised we were fighting the tool on multiple fronts. Performance, caching, hosting. That is when we decided to try something else.

Enter TanStack Start

We picked TanStack Start because it promised something boring that we actually wanted.

Simple routing. Clear data loading. No hidden magic.

It feels like React from before everything tried to be clever. You get file based routing, nested layouts, data loaders and type safety, without any mystery layers that silently cache or run on the server unless you tell them not to.

And it is fast.

Same project, new stack:

dev server spins up in about 2 seconds
page changes in development feel instant
navigation in production is snappy, like a proper SPA

We did the migration in a couple of weeks. Not full time, just squeezing it in while shipping other stuff. Most of the work was not even TanStack itself. We used the chance to:

upgrade a pile of outdated packages
move everything from CommonJS to ESM
clean up some old layout and routing hacks from the Next days

Moving the actual pages and routes was surprisingly straightforward.

Now the OpenPanel dashboard loads way faster and, more important, it feels predictable again. When something is slow or broken, it is our code, not some invisible cache layer or server boundary.

So when does this actually matter for you

If you are building:

a blog
a marketing page
a brochure style site
a simple shop

Stay on Next.js. Seriously. It is great for those things. You get SEO, image optimisation, static exports, all the goodies.

If you are building:

a dashboard
a complex tool
something where users click around a lot and expect instant feedback

Then at least try TanStack Start on a side project. Feel the difference.

TanStack is getting a lot of attention lately, and for good reason. The team moves fast, the community is growing, and it already has solid backing from sponsors. But it still feels grounded. You can actually read the code and understand what’s happening.

What you get is a simple mental model, strong TypeScript support, and performance that feels like old school React apps where you just shipped a bundle and called it a day.

That is why we switched. Not to be trendy. Not to be contrarian. Just to make OpenPanel nicer to work in and nicer to use.

If Next.js currently feels like a puzzle you never signed up for, you are not alone. There is a simpler option. And for us, TanStack Start has been exactly that.

If you have any questions, don't be shy, I'll try to answer them the best I can.