👋 Hey friends,

Here’s what I’ve got for you this week:

• A snippet from Chapter 4 of The Backend Lowdown

• Library recommendation: boundary

Let’s get into it 👇

The Backend Lowdown: Chapter 4 Preview

Stale-While-Revalidate (SWR)

When cached data expires, users shouldn't have to wait while your application recomputes expensive values. SWR solves this by always serving immediately from cache (even expired data) while quietly refreshing it in the background. Users get instant responses, your backend stays protected, and fresh data appears on the next request.

The pattern uses two expiration windows:

• Soft expiry: When to start background refreshes (data is stale but still acceptable)

• Hard expiry: When data is too stale to serve (forces synchronous refresh as a safety backstop)

When it helps

• High-traffic pages where any delay hurts user experience (search results, product listings)

• Cache refills that take multiple seconds (complex queries, external API calls)

• Traffic spikes or deployments when many keys expire simultaneously

• Any scenario where slightly stale data is better than making users wait

Dev Lib Recommendation

I’ve been deep in Elixir this year and stumbled on a library that got me thinking about architectural contracts. These are the seams between modules that keep big systems sane. When those seams blur, you get cycles, “reach-through” calls, and Law-of-Demeter drama.

Different ecosystems enforce these contracts differently. Ruby’s Packwerk and Python’s import-linter lean on static analysis in CI, while languages like Rust or Go give you compiler-enforced visibility at the module/package level. Elixir’s boundary (by Saša Jurić) is interesting because it brings compile-time boundary checks, and cycle detection, to a dynamic language.

Here’s the idea in 20 seconds: you declare what a namespace exports and which other namespaces it may depend on. If code crosses the line, the build fails. Simple, loud, and early.

# lib/my_app/accounts.ex – a boundary (usually a top-level context module)
defmodule MyApp.Accounts do
  use Boundary, deps: [MyApp.Billing], exports: [User, Accounts]
end

# lib/my_app/billing.ex – another boundary
defmodule MyApp.Billing do
  use Boundary, deps: [], exports: [Invoice]
end

# lib/my_app/accounts/reporter.ex – this will fail if it violates the contract
defmodule MyApp.Accounts.Reporter do
  alias MyApp.Billing.Invoice # ✅ allowed only because Accounts -> Billing is declared
  alias MyApp.Analytics.Event # ❌ would fail: Analytics not in Accounts.deps
end

I like this because it nudges you to name your public API, blocks sneaky cross-module imports, and catches cycles before they metastasize. Even if your system isn’t “big” yet, drawing the lines early pays compounding dividends.

When’s the last time you looked at the boundaries in your codebase?

That’s a wrap for this week. If something here made your day smoother, feel free to reply and tell me about it. And if you think a friend or teammate would enjoy this too, I’d be grateful if you shared it with them.

Until next time,
Steven