Category: Development

The event driven architecture: lifecycle events and offloading the heavy computation to a worker

A player finishes a ranked match and lands a new personal best. You write the result to the database, and now a few other things should happen. The leaderboard needs recomputing. The cached top ten is stale. A couple of friends should probably get a “you’ve been overtaken” notification. None of that has to finish before you tell the player “result saved”, but all of it has to happen eventually.

The obvious move is to keep that work out of the request. Drop it on a queue, let a worker pick it up, and respond right away. That’s event-driven thinking, and it’s the right instinct.

But “event” is one of the most overloaded words we use. Sometimes it means “do this thing, just not right now”, a note you leave for yourself. Sometimes it means “this happened, in case anyone cares”, an announcement to the world. On the wire they look the same: a message on a queue. In intent they’re opposites, and mixing them up is where a lot of event-driven designs quietly go wrong.

This post is about both jobs: offloading work inside your own app, and broadcasting facts to other services. Mostly it’s about where the line between them sits.

(more…)

Your startup doesn’t need microservices

A freelance developer recently posted on r/SaaS something that made me laugh because of how real it is. When a non-technical founder asks for a simple MVP, the build takes two weeks and the quote is reasonable. But when a founder asks for microservices and Kubernetes “so we can scale to millions,” the quote doubles.

Instead of a simple session handler, now there’s a separate Auth Service. That’s 10 billable hours. Instead of one SQL database, now there are three syncing via events. That’s a week of work. Instead of a $5 VPS, there’s a complex AWS cluster to configure. The app does the exact same thing. It just costs $5.000 a month to maintain instead of $50.

I’ve seen this play out too many times. So here’s my take on why microservices are almost always the wrong choice at the early stage, and what to do instead.

(more…)

Database-efficient API pagination

When designing APIs, you will probably need to handle a way to paginate the results in a collection.

Depending on the database you are using, the first thing that could come to your mind could be to use your database limit and offset to paginate the results. This may be tempting, but sometimes it could be better to rely on something else.

Imagine you have a list of messages in a chat application, and for the first call, you show the first 15 messages. Now you want to get the next page of results, say other 15 messages past the ones you already have, so you do LIMIT 15 OFFSET 15 in your database. Cool right?

(more…)