proomt

Search

Search posts, papers, and topics

Hall of Fame

Hall of FameJ. H. Saltzer, D. P. Reed, D. D. Clark198426 min readpaperintermediate

End-to-End Arguments in System Design

Read on mit.eduHN 6·1 comments

Summary

The paper defines the end‑to‑end argument: functions that can only be correctly implemented with knowledge of the application’s endpoints belong at the endpoints, not in lower layers. Low‑level mechanisms are justified only as performance enhancements, not as substitutes for end‑to‑end checks.

  • Place reliability, encryption, and duplicate suppression at the application endpoints when correctness requires end‑to‑end knowledge.
  • Low‑level services (e.g., checksum, retransmission) are useful only to improve performance, not to guarantee correctness.
  • A reliable data transfer protocol still needs an end‑to‑end checksum and retry logic despite a reliable link layer.
  • Implementing functions low in the stack can be uneconomical if failures are rare; end‑to‑end checks handle rare errors efficiently.

System and protocol designers should apply the end‑to‑end principle to avoid unnecessary complexity and cost while ensuring correctness.

9/10
securityarchitecturenetworkingdistributed systemsreliability

Related reading

  1. Go To Statement Considered Harmful

    Edsger Dijkstra argues that the `go to` statement should be abolished from higher-level programming languages due to its detrimental effect on program quality and readability. He posits that `go to` makes it difficult to reason about program state and progress, unlike structured control flow which provides clear, manageable execution coordinates.

    Hall of Fameutexas.edu7 min

  2. Constraint Decay: The Fragility of LLM Agents in Backend Code Generation

    A systematic evaluation of LLM agents generating multi‑file backend code shows a sharp drop in correctness when structural constraints (framework conventions, ORM usage, API contracts) are added. Across 100 tasks in 8 Python web frameworks, assertion pass rates fall ~27 points, with data‑layer bugs (bad queries, ORM violations) driving most failures. Mid‑size models cope with minimal frameworks (…

    arXiv cs.SE (Software Engineering)arxiv.org1 minpaperHN287197

  3. Write End-to-End Tests in Your Backend’s Language

    This article advocates writing end-to-end tests in the backend's language to leverage domain models and persistence tools for efficient test data setup. It details a strategy for structuring E2E tests with inline data creation, small helpers, and parallel execution considerations.

    Atomic Objectatomicobject.com7 min

  4. Hints for Computer System Design

    Lampson’s 1983 essay distills practical design hints for computer systems, emphasizing simple, well‑defined interfaces, predictable costs, and separating common‑case from worst‑case paths. The advice, illustrated with examples from Alto, Dorado, and early OSes, remains relevant for modern system architects.

    Hall of Famemicrosoft.com62 minpaper

  5. System Design Interviews for Data Roles: What to Actually Practice

    The piece shows that data‑role system design interviews evaluate how you turn vague requirements into a defensible architecture, not which tools you name, and it gives a concrete prep framework: clarify scope, quantify load, pick batch vs streaming with trade‑offs, and address failure handling. Candidates should rehearse explaining these decisions aloud with numbers rather than just drawing diagr…

    SitePointsitepoint.com6 min

  6. Article: Your Next DSL Author Is a Language Model

    Typed Domain Grounding (TDG) embeds a DSL inside a mainstream language the LLM already knows (e.g., Kotlin) and uses the host compiler as an oracle. The author describes five building blocks—embedding, choosing a host language with high training‑data frequency, compiler‑driven type safety, a generate‑compile‑repair loop, and an on‑demand teaching tool—and shows measured results from kUML, a Kotli…

    InfoQinfoq.com18 min