Language-agnostic service engineering: the protocols, boundaries, and failure handling that sit between a coding round and a full system design round.
12 published across 7 topics.
Backend engineering fundamentals56 short answers on one page, for revising rather than studying.Methods and status semantics, caching headers, content negotiation, and HTTP/2 and HTTP/3 differences.
Offset pagination gets slower with depth and drifts when rows are inserted mid-traversal, so paginate with a keyset comparison on the sort key plus a unique tiebreaker, hand back an opaque cursor and a Link rel=next header, and price an exact total count separately.
Get the method's safety, idempotency and cacheability right, use the status code intermediaries and clients act on rather than a generic 200 with an error body, pair Cache-Control freshness with ETag or Last-Modified validators, and be honest that most APIs called REST are resource-shaped HTTP without hypermedia.
Sessions versus tokens, OAuth 2 and OIDC flows, JWT validation pitfalls, and RBAC versus ABAC.
Model permission as a relationship between a subject, a role and a specific resource, not as a role stamped on the user, and push the check down into the data access predicate so a list query and a single-record fetch are authorised by the same rule.
Default to server-side sessions in an opaque HttpOnly cookie, because revocation is a row delete and the browser cannot read the credential. Choose JWTs only when a resource server must validate without calling the issuer, keep them short-lived, and pin the algorithm, issuer, audience and expiry on every verification.
Service boundaries, data ownership, saga and outbox patterns, and when a monolith is the right answer.
Additive changes with defaults are safe, removals are not, so split every removal into deprecate-then-delete with evidence that nobody reads the field. Register the schema, pick a compatibility mode deliberately, and note that backward compatibility requires consumers to deploy first.
Draw boundaries on data ownership so exactly one service writes each table, then accept that a workflow crossing them needs a saga of compensating steps and an outbox to make the write and the publish atomic. While the boundaries are still moving, a modular monolith is the honest answer.
Timeouts, retries, idempotency keys, dead-letter queues, and designing for partial failure.
A timeout shorter than the caller's patience is the only defence that works without cooperation. Retries need idempotency, jitter and a budget or they amplify the outage; a breaker must trip on latency as well as errors; and a bulkhead is what stops one slow dependency consuming every thread.
Take an idempotency key from the client and store it in a uniquely-constrained row written in the same transaction as the effect, so the dedupe record and the work commit together. Replay the stored response on a repeat, refuse a retry arriving mid-flight, and expire keys past the retry horizon.
Schema design, N+1 resolution, streaming RPC, and choosing a protocol per consumer.
Choose per consumer: GraphQL where many client shapes make over-fetching the problem, gRPC for internal traffic wanting typed generated stubs and streaming, plain JSON over HTTP for partners who want curl and a CDN. Then batch your resolvers, because the N+1 is structural.
Time and ordering, leader election, quorums, idempotence, and classic impossibility results.
Wall clocks on separate machines disagree by an unbounded amount and can jump backwards, so their timestamps order events by accident rather than by causality. Logical and vector clocks capture what preceded what, quorums give overlap not order, and a lease is safe only with a fencing token.
Production situations to diagnose out loud: latency spikes, memory growth, cascading failures, bad deploys.
Lag is the integral of arrival rate minus service rate, so establish which of the two moved and whether the consumer is slow or stalled. Check lag per partition before per group, rule out a rebalance loop, and remember that adding consumers beyond the partition count does nothing.
A flat p50 rules out a uniform slowdown, so the tail belongs either to a subset of requests or to a queueing effect. Partition the latency histogram by instance, endpoint and tenant before naming a cause, then confirm with traces, GC logs and pool-wait metrics.