Search the practice set
275 questions, 991 terms and 600 topics in 30 areas.
60 results for “Component Contracts”
Prop Interface Stability
The commitment a component makes about its props, slots, events and emitted structure — including the parts consumers depend on that were never intended as interface.
Component Library Versioning
Treating a design system as a versioned product with a compatibility policy and a deprecation process, because its consumers cannot all upgrade at once.
Abstraction
Exposing what a component does while hiding how it does it, so callers depend on the contract rather than the mechanism.
Backpressure
A mechanism by which a component under load tells its callers to slow down, rather than accepting work it cannot complete.
Backward Compatibility
The property that a new version of a producer continues to work with clients written against the old version.
Blast Radius
The set of things that break, or become reachable, when one component fails or is compromised.
Broker and Mediator Topology
Two ways of organising an event-driven system — components reacting independently to a shared channel, or a central component coordinating a defined sequence.
Burn Rate Alerting
Paging when the error budget is being consumed fast enough to matter, rather than when a component crosses a threshold.
Byzantine Fault
A failure in which a component behaves arbitrarily or deceptively — returning wrong results rather than stopping — as distinct from simply crashing.
C4 Model
A set of four nested diagram levels — context, container, component, code — that keeps each diagram at one consistent level of abstraction.
Cell Router
The thin component that maps a request to its cell, and which is the one shared dependency a cell-based architecture must keep minimal.
Client Runtime Constraint
The properties of the browser or device you do not control — CPU, network, version, extensions — which make the client a distributed system component rather than a rendering surface.
Cohesion
The degree to which everything inside one component belongs together and changes for the same reason.
Consumer Contract
A machine-readable record of exactly which parts of a provider's response one consumer relies on, generated from that consumer's own tests.
Consumer-Driven Contract
A contract derived from what consumers actually use, published to the provider, and verified in the provider's own build.
Coupling
The degree to which one component must know about, or change alongside, another.
Encapsulation
Keeping a component's state private, so it can only be changed through operations that maintain its invariants.
Fail-Fast vs Fail-Safe
Whether a component should stop immediately on detecting a problem, or continue in a degraded but safe mode — a choice that depends entirely on which outcome is worse.
Failover Orchestration
The sequence of detection, decision, promotion and traffic redirection that moves service from a failed component to a healthy one.
Failure Thinking
Making "what happens when this fails?" a standing question applied to every component and every dependency in a design.
Grey Failure
A component that is degraded rather than down — slow, intermittently erroring, or failing for a subset of operations — which defeats health checks built for binary states.
Idempotency Token Store
The durable record of which idempotency keys have been seen and what each one returned, and the component that decides whether the guarantee is real.
Managed Service Substitution
Replacing a self-managed component with a managed equivalent during migration, without changing the application's architecture.
Mesh Control Plane
The component that configures and coordinates a service mesh's data plane proxies, distributing policy, identity and routing rules.
Message Router
A component that inspects a message and forwards it to one of several destinations based on its content or headers.
Message Translator
A component converting a message between two systems' formats, so neither has to adopt the other's model.
OpenAPI
A machine-readable specification format for HTTP APIs, from which documentation, clients, servers, mocks and validation can be generated.
Operational Burden Assessment
Quantifying the ongoing engineering effort a self-managed component requires, so it can be compared honestly with a managed service's price.
Output Validation Layer
A deterministic check applied to model output before it is used, treating the model as an untrusted component.
Process Manager
A component that owns the state and sequencing of a multi-step business process, deciding what happens next in response to events.
Producer Obligation
What a data contract binds the producing team to do, and — crucially — what happens in their pipeline when they are about to break it.
Projection
The process that consumes changes from the write side and maintains a read model, and the component where most CQRS bugs live.
Provider Verification
The provider-side stage that replays every consumer's recorded expectations against the real implementation.
REST
An architectural style for APIs built on resources identified by URLs, manipulated with uniform HTTP methods, and stateless requests.
Redundancy
Having more instances of a component than the load requires, so that failures can be absorbed without loss of service.
Review Latency
The time between a change being ready for review and the review happening, which is usually the largest component of lead time.
STRIDE
A mnemonic for six threat categories — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege — walked across each component and data flow.
Saga Orchestrator
A component that explicitly drives a saga's steps and compensations, holding the flow in one place rather than distributing it across event subscriptions.
Semantic Diffing of API Schemas
Comparing the published contract between builds and failing the build on a breaking change, so compatibility is mechanical rather than remembered.
Semantic Versioning
A version scheme where the number itself states the compatibility promise — major for breaking, minor for additive, patch for fixes.
Service Level Agreement
A contractual commitment about service level, with a defined remedy — usually a service credit — when it is missed.
Software Bill of Materials
A machine-readable inventory of every component and dependency in a piece of software, including transitive ones, used to answer exposure questions quickly.
Spike and Prototype
A time-boxed experiment run to reduce uncertainty about a specific question, producing evidence rather than a component.
Temporal Coupling
A dependency in which one component requires another to be available at the same moment, so the availability of both is required for either to work.
Application teams say the platform is unreliable. The platform team's dashboard shows 99.95% on every component. How do you resolve this?
Both are right, and that is the finding The platform measured its components. Consumers experience journeys. The gap between those two views is where trust erod
A dashboard has been wrong for three weeks. Nobody knows which upstream produced the table it reads. What is the governance failure, and what fixes it?
The failures, and there are three 1. No lineage. The question "which upstream produced this?" should be answerable in seconds by following a derived dependency
A quarterly board report shows a category down 40%. Investigation finds an upstream system stopped sending a field three months ago. Nothing alerted. What do you change?
Understand why nothing fired The pipeline completed successfully every night. It read the source, applied its transformation, and wrote rows — all of which is w
A team proposes exposing their service's database change stream via CDC so other teams can consume it, avoiding the work of building an event API. What is your assessment?
Name what is actually being proposed The proposal is to publish the service's internal schema as its integration contract. CDC does not emit domain events; it e
Component Contracts
Props, slots and events as an interface, and the breaking change hidden in a style.
Consumer-Driven Contracts
Consumers declaring what they rely on, and providers verifying against those declarations.
Data Contracts
Producers committing to schema, semantics and freshness, and breaking builds when they do not.
API & Integration
General material on integrating systems through contracts.
C4 Model
Context, container, component and code as four separate diagrams.
Coupling
How much one component must know about, or change alongside, another.
Partner & B2B Integration
External contracts, onboarding, sandboxes and long deprecation windows.
Platform APIs
Treating the platform's own interfaces as contracts with consumers and compatibility rules.