Follow Us

Our Blog

Home | Our Blog
Technology 2 min read

Five Architecture Decisions I Would Not Undo

Ali Omoum

Ali Omoum

Dec 27, 2025
7 Comments
Five Architecture Decisions I Would Not Undo

Architecture is a sequence of one-way doors. You walk through, and the choice you made shapes the next ten years of decisions. Here are five doors I'm glad I walked through, and one I keep questioning.

1. Pick PostgreSQL by default

For 95% of applications, PostgreSQL is the right database. It's relational, it's mature, it has full-text search, JSONB, partial indexes, partitioning, and a community that's been answering hard questions for thirty years. Reach for something else when you have a specific reason — never because someone said NoSQL is "modern".

2. Server-render first, hydrate when needed

Single-page apps tax your team forever: routing, state, hydration, code splitting, accessibility, SEO, perf. For dashboards behind a login, fine. For public-facing or content-heavy sites, server-rendered HTML with a sprinkle of JavaScript outperforms a SPA on every metric except tooling vanity.

3. Background jobs are infrastructure, not optional

Once a system has more than one writer, you need a queue. Treat it as a first-class part of the architecture — observable, retryable, idempotent — not a quick afterthought.

4. One database per tenant is fine

For multi-tenant SaaS, separate databases per tenant gives you cleaner backups, easier per-tenant migrations, and natural isolation. The only price is operational complexity, and modern tooling (Postgres + connection pooling + automation) makes that cheap.

5. Domain events, not CRUD

Modeling your write API as "here's a CRUD endpoint for this row" is a habit that bites you the moment business logic gets interesting. Modeling it as "here's an event that means something happened" compounds in your favor: audit logs, integrations, undo, replay, analytics — all become natural.

The one I'd think twice about

Adopting microservices before there were ten engineers. The boundaries that look obvious on a whiteboard turn out to cut through the most active code. If you have to refactor every release, you don't need new services — you need different boundaries inside one service.

Comments (7)

  • Ali Omoum
    By Ali Omoum

    This article helped me understand technical SEO better. Much appreciated!

    • Ali Omoum
      By Ali Omoum

      Thanks for the insight! I was wondering the same.

  • Ali Omoum
    By Ali Omoum

    Can you share more about keyword placement in headings?

    • Ali Omoum
      By Ali Omoum

      Thanks for the insight! I was wondering the same.

  • Ali Omoum
    By Ali Omoum

    I've been struggling with local SEO — this clarified a lot.

  • Ali Omoum
    By Ali Omoum

    What are your thoughts on AI-generated content and SEO?

    • Ali Omoum
      By Ali Omoum

      Thanks for the insight! I was wondering the same.

Login to comment

To post a comment, you must be logged in. Please login. Login