Backend­Bytes

Backend Architect's Checklist

Twenty questions to work through before finalising a backend stack decision. Pair with a whiteboard. Answer each in one sentence; the quality of the answer tells you whether the decision is ready.

Version 0.1 · April 2026 · Updated quarterly

Get quarterly updates

1. Data & Persistence

  1. 1. Do you need strong consistency or can you tolerate eventual?

    If the answer isn't obvious from the product spec, you haven't defined your consistency model yet. Pick a canonical operation (“user transfers money” / “follower count updates”) and decide for that one first.

  2. 2. What's your expected write-to-read ratio at 12 months?

    A 1:100 read-heavy workload wants different primitives than 1:1. If the estimate is “I don't know”, your scale plan is guesswork and you should size for the cheaper case then monitor.

  3. 3. What's your primary access pattern?

    “By user id” points to KV or a row store. “By a range of timestamps” points to an index on that field (or a time-series store). “By arbitrary filters over the dataset” points to a query engine. Pick the store that makes your primary pattern O(1), not the one that makes every pattern mediocre.

  4. 4. How much data at 12 months and 36 months?

    If the 36-month number doesn't fit on a single machine's RAM plus reasonable SSD, you're buying yourself a sharding project. That's fine, but name it now.

  5. 5. What's your backup and PITR (point-in-time recovery) target?

    “We take snapshots” isn't an answer. Define the RPO (how much data can you lose) and RTO (how long can you be down). Your store choice changes materially if RPO must be under 5 minutes.

2. Traffic & Protocol

  1. 6. Sync or async at the edge?

    If “the user waits for the response” is true, you're sync, and p99 latency is a product requirement. If not, you can probably front with a queue and the whole shape of the system changes.

  2. 7. REST, gRPC, GraphQL, or WebSockets?

    REST for public APIs and simple client teams. gRPC for internal service-to-service where latency matters. GraphQL when the client needs arbitrary shapes over a fixed graph. WebSockets for bidirectional real-time. Avoid “all of them” — pick one primary surface.

  3. 8. What's the unit of idempotency?

    Every non-GET endpoint needs one. An order id, a client-generated UUID, a request hash. Without it, retries create duplicates and every bug becomes twice as bad as it should be.

  4. 9. How will you rate-limit?

    Per IP, per user, per API key, or per endpoint? Pick before launch. Production without rate limiting is one bad bot away from an outage (or a bill spike).

  5. 10. What's the caching layer?

    Client cache (Cache-Control headers), CDN cache (edge), in-process cache (per-instance memory), shared cache (Redis). Each has a different invalidation story. Pick one primary and know how you invalidate it before you deploy.

3. Reliability & Observability

  1. 11. What's your SLO and error budget?

    “99.9% availability” is 43 minutes of downtime per month. If you haven't agreed on a target with the product team, your on-call policy is guesswork. Write it down.

  2. 12. How do you detect outages?

    Synthetic probes hitting a health endpoint, real-user monitoring, or waiting for a customer to email. Pick the first two; the third is the one you're trying to prevent.

  3. 13. What do your three observability pillars look like?

    Metrics (Prometheus-compatible), logs (structured JSON, centralised), traces (OpenTelemetry). You don't need to ship all three on day one, but you need to agree which comes first and stick to the conventions before you have 50 services.

  4. 14. What's your deploy strategy and rollback time?

    Rolling / blue-green / canary, and under 5 minutes to fully roll back. If you need to SSH into boxes to roll back, you're a bad hour from an incident.

  5. 15. Circuit breakers and timeouts — are they explicit?

    Every outbound call has a timeout. Every dependency has a circuit breaker or a bulkhead. No defaults — declare them. When a downstream gets slow, your service should degrade, not queue requests until it falls over.

4. Security & Operations

  1. 16. How do you authenticate, and with what token lifetime?

    OAuth2 / OIDC for user auth, short-lived access tokens (minutes), longer-lived refresh tokens (days). Never invent your own authentication protocol unless you have a very specific reason and a security team to back you.

  2. 17. Where do secrets live?

    A secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager), not env vars baked into images, not config files in the repo. If you can't rotate a secret in under an hour, you don't own your secrets.

  3. 18. PII handling — what are your retention and deletion policies?

    GDPR / CCPA / LGPD all require deletion on request. Design for it from day one — know which tables hold PII, how you cascade deletes, and how long you retain logs.

  4. 19. What's your dependency update cadence?

    Weekly patch releases, monthly minor, quarterly major. Schedule the time in advance. “We'll update when something breaks” is how CVEs become outages.

  5. 20. Who owns this in six months?

    If the answer is “the person who built it” and that person might leave, your runbooks, on-call rotation, and knowledge transfer aren't ready. Build the team before you build the system.