Manu's Vault

Strict vs Loose Contracts

6 min readStatus:Seedling

Core Idea

Strict vs.

Definition

Strict vs. Loose Contracts describes the spectrum of contract flexibility in distributed systems—the degree to which service interfaces rigidly enforce schema conformance versus gracefully accommodate variations and extensions. A strict contract requires exact matching of all specified fields and types, rejecting any deviation as an error. A loose contract follows the robustness principle (Postel’s Law): “Be conservative in what you send; be liberal in what you accept,” allowing services to ignore unknown fields and accept compatible variations.

This trade-off fundamentally shapes how distributed architectures handle evolution, versioning, and backward/forward compatibility.

Key Characteristics

  • Validation strictness: Strict contracts validate every field and reject unexpected data; loose contracts accept superset schemas and ignore unrecognized elements

    • Strict: All request/response fields must match specification exactly
    • Loose: Consumers ignore fields they don’t understand, producers send minimal required data
    • Tools like JSON Schema can enforce strict validation, while Protocol Buffers naturally support loose interpretation

  • Backward compatibility: Loose contracts enable old clients to work with new services by ignoring new optional fields

    • New version adds fields → old clients continue functioning unchanged
    • Reduces coordination overhead for deploying service updates
    • Requires careful design to avoid breaking changes (removing fields, changing types)

  • Forward compatibility: Loose contracts allow old services to process requests from new clients by safely ignoring unknown fields

    • New client sends additional fields → old service processes known fields and ignores rest
    • Enables gradual rollout where client upgrades precede service upgrades
    • Critical in decentralized systems where deployment timing cannot be controlled

  • Versioning implications: Strict contracts often require explicit versioning (/v1, /v2) for any change; loose contracts reduce version proliferation

    • Stripe API demonstrates hybrid approach: evolution for non-breaking changes, explicit versions only for major breaking changes
    • Loose contracts allow single-version APIs to evolve continuously
    • Trade-off: Loose contracts may hide actual usage patterns from producers

  • Error visibility vs. resilience: Strict contracts catch incompatibilities early through validation failures; loose contracts prioritize resilience by processing what they understand

    • Strict: Fail-fast behavior surfaces integration problems immediately
    • Loose: Graceful degradation allows partial functionality even with schema mismatches
    • Choice depends on context: financial transactions favor strict; data collection favors loose

  • Schema evolution burden: Loose contracts shift responsibility to producers to maintain compatibility; strict contracts force consumers to upgrade in lockstep

    • Loose: Producer must ensure new schemas don’t break old consumers (additive changes only)
    • Strict: Consumers must update whenever producer changes
    • Impacts organizational coupling and deployment independence

Examples

  • Strict contract: GraphQL API rejects requests containing unknown fields, enforcing exact schema match

    • Benefit: Catches client errors early, prevents accidental reliance on non-existent fields
    • Cost: Every schema change requires coordinated client updates

  • Loose contract: REST API using Protocol Buffers ignores unknown fields in requests, processes known fields normally

    • Benefit: Old service versions continue working as clients upgrade
    • Cost: May silently ignore client errors (typos in field names), harder to detect misuse

  • Hybrid approach: OpenAPI specification with additionalProperties: false for critical requests (payments), additionalProperties: true for extensible entities (user profiles)

    • Balances safety for high-risk operations with flexibility for evolving data models

  • Message queue contracts: Kafka consumers using Avro schemas with backward compatibility mode—new messages add optional fields that old consumers safely ignore

    • Enables producer/consumer teams to deploy independently
    • Schema registry validates compatibility before allowing new schemas

  • Database schema evolution: Adding nullable columns (loose—old code ignores new columns) vs. adding NOT NULL columns (strict—requires all code to provide values)

Why It Matters

Contract flexibility is a first-order architectural decision that determines team autonomy, deployment independence, and system resilience. Loose contracts enable microservices to evolve independently—critical for organizational scalability where dozens of teams must deploy without coordination. They reduce the “blast radius” of changes, allowing gradual rollouts and canary deployments.

However, strict contracts provide stronger guarantees and clearer error messages. They prevent subtle bugs where clients send malformed data that gets silently ignored. Research on microservice evolution shows that ineffective communication of changes and consumer reliance on outdated versions cause API design degradation—strict contracts make incompatibilities explicit through validation failures rather than runtime surprises.

The choice cascades through the architecture: loose contracts pair naturally with asynchronous messaging, eventual consistency, and choreography; strict contracts align with synchronous RPC, ACID transactions, and orchestration. Understanding this trade-off is essential for making coherent architectural decisions that don’t create contradictory constraints.

Sources

  • Ford, Neal; Richards, Mark; Sadalage, Pramod; Dehghani, Zhamak (2022). Software Architecture: The Hard Parts - Modern Trade-Off Analyses for Distributed Architectures. O’Reilly Media. ISBN: 9781492086895.

    • Discusses strict vs. loose contract trade-offs in distributed architectures
    • Chapters on interservice communication and contract design patterns

  • Postel, Jon (1980). “DoD Standard Internet Protocol.” RFC 760. Internet Engineering Task Force.

  • Schermann, Gerald; Cito, Jürgen; Leitner, Philipp (2016). “Continuous Experimentation: Challenges, Implementation Techniques, and Current Research.” IEEE Software, Vol. 33, No. 2, March-April 2016, pp. 26-31.

    • DOI: 10.1109/MS.2016.27
    • Discusses contract evolution challenges in continuous deployment contexts

  • Basurto, Ana; Pautasso, Cesare (2024). “Microservice API Evolution in Practice: A Study on Strategies and Challenges.” Information and Software Technology, Vol. 174, 2024.

  • Kleppmann, Martin (2017). Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. O’Reilly Media. ISBN: 978-1-449-37332-0.

    • Chapter 4: “Encoding and Evolution” - comprehensive treatment of schema evolution, backward/forward compatibility
    • Discusses Avro, Protocol Buffers, and Thrift compatibility guarantees

  • Microsoft Learn (2024). “Creating, evolving, and versioning microservice APIs and contracts.”

  • InfoQ (2009). “Contract Versioning, Compatibility and Composability.” By Stefan Tilkov.

    • Definition of backward and forward compatibility in service contracts
    • “A new version of a contract that continues to support consumers designed to work with the old version is considered to be Backwards Compatible”
    • Available: https://www.infoq.com/articles/contract-versioning-comp2/

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks