A backend engineer exists to keep the truth. Behind every interface is data that\nmust stay correct when thousands of requests touch it at once, when machines\ncrash mid-write, when the network drops a message after the work was already\ndone. The backend is where a button click becomes a durable fact — money moved,\nan order placed — and where it must stay a fact even though the systems doing the\nwork are unreliable, concurrent, and distributed across machines that fail\nindependently. Correctness under concurrency and partial failure is genuinely\nhard, and getting it wrong means double-charged customers, lost orders, and data\nthat quietly disagrees with itself.
\n","wordCount":108},{"heading":"Core Mission","id":"core-mission","markdown":"Serve correct data and durable state under concurrency and partial failure, so\nthat the same request twice, a crash mid-operation, or a slow dependency never\ncorrupts the truth.","html":"Serve correct data and durable state under concurrency and partial failure, so\nthat the same request twice, a crash mid-operation, or a slow dependency never\ncorrupts the truth.
\n","wordCount":29},{"heading":"Primary Responsibilities","id":"primary-responsibilities","markdown":"The visible work is writing endpoints; the actual work is designing data models\nand the guarantees around them. A backend engineer designs APIs as contracts that\noutlive the code behind them; models the data store, since the schema is the most\nexpensive decision and the hardest to change; reasons about concurrency — locks,\ntransactions, isolation levels, the races between them; makes operations\nidempotent so a retried request doesn't double-charge; handles partial failure\nwith timeouts, retries, circuit breakers, and back-pressure; designs for\nthroughput and tail latency under load; secures the perimeter where\nauthentication and untrusted input meet; and operates the service in production.\nThe discipline underneath is thinking in invariants: what must always be true, no\nmatter what fails.","html":"The visible work is writing endpoints; the actual work is designing data models\nand the guarantees around them. A backend engineer designs APIs as contracts that\noutlive the code behind them; models the data store, since the schema is the most\nexpensive decision and the hardest to change; reasons about concurrency — locks,\ntransactions, isolation levels, the races between them; makes operations\nidempotent so a retried request doesn't double-charge; handles partial failure\nwith timeouts, retries, circuit breakers, and back-pressure; designs for\nthroughput and tail latency under load; secures the perimeter where\nauthentication and untrusted input meet; and operates the service in production.\nThe discipline underneath is thinking in invariants: what must always be true, no\nmatter what fails.
\n","wordCount":119},{"heading":"Guiding Principles","id":"guiding-principles","markdown":"- **Correctness under concurrency beats raw speed.** A fast endpoint that\n occasionally double-writes is a liability. Get the invariants right first.\n- **Make every write idempotent.** The network will deliver your message zero,\n one, or many times. Design so \"again\" is always safe.\n- **The database is the source of truth; the cache is a convenience that lies.**\n Treat every cached value as potentially stale and plan for the miss.\n- **Push correctness into the data layer.** Constraints, foreign keys, and unique\n indexes enforced by the database survive bugs in the application above.\n- **Design the API for the consumer, version it for the future.** A public\n contract is forever; breaking it breaks people you'll never meet.\n- **Fail fast, degrade gracefully, never silently.** A clear error beats a hung\n request.\n- **Measure tail latency, not averages.** The p99 is what your worst-served users\n feel, and where the system is about to fall over.","html":"EXPLAIN, and\nindex design are core craft.The backend engineer owns the contracts other people build on, which makes API\ndesign a social act. With frontend and mobile engineers, the daily negotiation\nis the API shape — chatty vs. coarse endpoints, error formats, pagination, who\nvalidates what; designing responses around the consumer's screen, not the\ndatabase's tables, saves everyone churn. With data engineers, the seam is the\nevent stream and the schema feeding the warehouse; breaking a field breaks\npipelines downstream. With SREs, they share ownership of the running service and\nits SLOs. With security engineers, the backend is the perimeter where authn/authz\nand untrusted input are enforced. The recurring tension is data ownership across\nservice boundaries — who may write a given table, and through what contract.
\n","wordCount":120},{"heading":"Ethics","id":"ethics","markdown":"The backend is where the consequential data lives — payments, health records,\nidentities, location histories — and where the engineer's choices are invisible\nto the user but binding on them. The duties: store only the data the product\ngenuinely needs and delete it when its purpose ends; encrypt sensitive data at\nrest and in transit and treat a breach as a foreseeable event whose blast radius\nyou must minimize; enforce least privilege so one compromised credential can't\nread everything; honor deletion and export requests because a user's data is\ntheirs; and be honest in design reviews about the risk of a schema or access\npattern rather than shipping a known time bomb. The power is quiet — a backend\nengineer can usually query any user's data — and the discipline of not doing so,\nand of building systems that make misuse hard and auditable, is the job.","html":"The backend is where the consequential data lives — payments, health records,\nidentities, location histories — and where the engineer's choices are invisible\nto the user but binding on them. The duties: store only the data the product\ngenuinely needs and delete it when its purpose ends; encrypt sensitive data at\nrest and in transit and treat a breach as a foreseeable event whose blast radius\nyou must minimize; enforce least privilege so one compromised credential can't\nread everything; honor deletion and export requests because a user's data is\ntheirs; and be honest in design reviews about the risk of a schema or access\npattern rather than shipping a known time bomb. The power is quiet — a backend\nengineer can usually query any user's data — and the discipline of not doing so,\nand of building systems that make misuse hard and auditable, is the job.
\n","wordCount":143},{"heading":"Scenarios","id":"scenarios","markdown":"**The double-charged customer.** Support reports occasional double charges. The\nexpert traces it: the payment endpoint isn't idempotent, and the mobile client\nretries on a slow network, so a single \"pay\" can hit the processor twice. The fix\nisn't \"make the network faster\" — it's an idempotency key generated by the client\nand stored with a unique constraint, so the second request finds the first's\nresult and returns it instead of charging again. The rule that follows: every\nstate-changing endpoint gets an idempotency key from day one, because retries are\nnormal behavior on an unreliable network, not an edge case.\n\n**The order-and-email dual write.** An order service writes the order, then\npublishes an \"order placed\" event to Kafka for email and fulfillment.\nOccasionally the process crashes between the two, leaving orders that exist but\nwere never fulfilled; publishing first just inverts the bug. The expert applies\nthe outbox pattern: write the event into an outbox table in the *same\ntransaction* as the order, then a relay reads the outbox and publishes. The\ncommit becomes the single atomic point of truth, and at-least-once delivery plus\nidempotent consumers makes it safe.\n\n**A read that's melting the database.** A dashboard endpoint slows to seconds\nunder load. `EXPLAIN` shows a sequential scan: the query filters on an unindexed\ncolumn, and a list view fires one query per row (N+1). The expert adds the\ncomposite index matching the filter and sort, batches the per-row queries into a\nsingle `IN`, and caches the now-cheap read with a short TTL. p99 drops from 3 s\nto 40 ms. The lesson: the index is part of the feature, not a later optimization.","html":"The double-charged customer. Support reports occasional double charges. The\nexpert traces it: the payment endpoint isn't idempotent, and the mobile client\nretries on a slow network, so a single "pay" can hit the processor twice. The fix\nisn't "make the network faster" — it's an idempotency key generated by the client\nand stored with a unique constraint, so the second request finds the first's\nresult and returns it instead of charging again. The rule that follows: every\nstate-changing endpoint gets an idempotency key from day one, because retries are\nnormal behavior on an unreliable network, not an edge case.
\nThe order-and-email dual write. An order service writes the order, then\npublishes an "order placed" event to Kafka for email and fulfillment.\nOccasionally the process crashes between the two, leaving orders that exist but\nwere never fulfilled; publishing first just inverts the bug. The expert applies\nthe outbox pattern: write the event into an outbox table in the same\ntransaction as the order, then a relay reads the outbox and publishes. The\ncommit becomes the single atomic point of truth, and at-least-once delivery plus\nidempotent consumers makes it safe.
\nA read that's melting the database. A dashboard endpoint slows to seconds\nunder load. EXPLAIN shows a sequential scan: the query filters on an unindexed\ncolumn, and a list view fires one query per row (N+1). The expert adds the\ncomposite index matching the filter and sort, batches the per-row queries into a\nsingle IN, and caches the now-cheap read with a short TTL. p99 drops from 3 s\nto 40 ms. The lesson: the index is part of the feature, not a later optimization.
A backend engineer is a software engineer specialized toward data, concurrency,\nand distributed systems, trading the rendering and accessibility concerns of the\nclient for invariants and throughput. The frontend engineer owns the other side\nof the API contract. Data engineers consume the backend's event streams to build\npipelines and warehouses. Database administrators tune and operate the stores the\nbackend designs schemas for. SREs share ownership of the running service and its\nSLOs, and security engineers harden the perimeter the backend enforces. Cloud\narchitects shape the substrate — queues, databases, networks — the backend runs\non.
\n","wordCount":93},{"heading":"References","id":"references","markdown":"- *Designing Data-Intensive Applications* — Martin Kleppmann\n- *Release It!* — Michael Nygard\n- *Database Internals* — Alex Petrov\n- *Patterns of Enterprise Application Architecture* — Martin Fowler\n- *Web Scalability for Startup Engineers* — Artur Ejsmont","html":"