← Back to the journal
Engineering /

The quiet case for a boring stack

A small app doesn’t need a small version of a big company’s infrastructure. Notes on choosing tools you can live with.

A quiet desk with a monitor, laptop and paper notebook.
Photo by Zesan H. / Unsplash ↗

There is a particular kind of procrastination that looks remarkably like good engineering. You start with a small problem. A few hours later, you have a deployment diagram, three queues, and a surprisingly strong opinion about service discovery.

The original problem is still there.

Start with the thing that must work#

Imagine a small application that lets a team collect customer requests. It needs accounts, a database, a couple of forms, and an email when something changes. That is a useful description of the system. “Event-driven platform” is not.

For a first version, I would rather understand one application and one database thoroughly than understand six services approximately.

A smaller starting point
from django.db import transaction
def create_request(*, customer, message):
with transaction.atomic():
request = Request.objects.create(
customer=customer,
message=message,
)
transaction.on_commit(
lambda: notify_team(request.pk)
)
return request

This sketch deliberately leaves an important question open: what happens if the notification fails? For a real application, I would choose retries, an outbox, or a queue based on the consequence of losing that message. A compact example is a place to begin asking questions, not a reliability guarantee.

Boring is a relationship#

A tool is boring when you know how it behaves at the edges. You know how to back it up. You know where the logs live. You have an idea of what will happen when you restart it.

That makes “boring” personal. The right choice for an experienced Go developer might be a terrible first choice for someone who has shipped several Django applications.

Choose a stack you can explain on a tired Tuesday afternoon.

Earn the next moving part#

When a limitation becomes concrete, write it down. A job takes too long. A deployment interrupts readers. A query misses its budget. Then make the smallest change that addresses that limitation.

There is nothing virtuous about keeping a system small after it has stopped serving its users. There is also no prize for making it complicated before it needs to be.

What is the simplest stack you have happily kept in production? I would love to hear what made it work — especially the unglamorous bits.

Thanks for reading.
Keep a little room for curiosity. — Q.
BETTER WITH OTHER PERSPECTIVES

Comments

Demo discussion

Different experience? A better approach? Leave a thought.

Preview only. Comments are saved in this browser, not published.