Engineering / backend

Backend systems

A backend is a set of contracts under load: data shape, failure semantics, latency, and the boundary where trust changes.

Small contracts

The API should make the normal response and the failure response equally legible. Typed envelopes, explicit validation, and a narrow route surface reduce the amount of implicit behaviour a client has to guess.

  • Validate at the boundary and return field-level feedback where a human can act on it.
  • Keep persistence details behind one data-access layer.
  • Use idempotent operations when a client may retry after a timeout.

Data is a product decision

SQLite and D1 are a good fit for a portfolio because the content is relational, modest in volume, and read-heavy. The important choice is not the brand of database but keeping migrations, seed data, and row mapping reviewable.

A schema is part of the interface. Treat a migration as a change to the product, not housekeeping.

Failure first

Timeouts, partial writes, duplicate submissions, and stale reads should be ordinary cases in the design. The happy path is only one branch of the contract.

Backend systems — Gokul Upadhyay Guragain