#Backend

Stop sending notifications for users who never confirm their email. This guide walks through a clean, event-driven architecture using Supabase, Postgres triggers, and Next.js webhooks—no edge functions required.

You don’t scale by upgrading your server forever. You scale by splitting your data across machines.

Distributed systems don’t fail loudly. They fail silently—with bad data.

Regional network blocks aren’t edge cases—they’re production realities. Supabase’s recent post highlights a growing blind spot in modern system design: assuming the internet is always reachable.

If I design things well enough, my system will behave predictably.

Distributed systems don’t just store data—they argue about what’s true. Chapter 9 breaks down how systems reach agreement (or fail trying), why consistency is hard, and how consensus algorithms keep everything from falling apart.

“The limits of my language mean the limits of my world.” — Ludwig Wittgenstein

Just copy the data to another server.

Your system doesn’t break when you deploy it. It breaks when old data meets new code. That’s the uncomfortable reality of software: data outlives everything. You can rewrite your frontend. You can refactor your backend. You can even replace your database. But your data? It sticks around quietly waiting to expose every bad decision you made six months ago.

Choosing the right API paradigm can make or break your system. Here’s a deep dive into REST, RPC, GraphQL, and event-driven APIs—and how to pick the right one.

Your beautiful data model eventually turns into… bytes on disk.

Batch processing doesn’t sound sexy.

“The Internet was done so well that most people think of it as a natural resource… rather than something that was man-made.” — Alan Kay

Most developers build features. I wanted to build systems. So instead of another CRUD app, I started building a real-time chat backend in Go—something simple on the surface, but brutal underneath.