# Architecture principles whose scope is service

> 82 records

This index as JSON: https://banes-lab.com/json/api/facets/architecture/scope/service

## Entries

- [Bounded Context](https://banes-lab.com/records/architecture/bounded-context.md): A rule or precondition that each domain model holds inside one explicit boundary, where its terms have one meaning.
- [Explicit Boundaries](https://banes-lab.com/records/architecture/explicit-boundaries.md): A design rule that each module declares its public interface and owner, and other modules reach it only through that interface.
- [Runtime Discovery](https://banes-lab.com/records/architecture/runtime-discovery.md): A mechanism that finds the available handlers, plugins or services at startup by matching a naming convention, a file pattern or metadata, and registers each one it finds in place of a hand-written list.
- [Service Discovery](https://banes-lab.com/records/architecture/service-discovery.md): A mechanism that resolves a service name to a healthy network endpoint at call time through a registry.
- [Dynamic Binding](https://banes-lab.com/records/architecture/dynamic-binding.md): A mechanism that selects the implementation behind an interface at runtime, from configuration or a registry, so the choice is made at bootstrap or first use rather than fixed in code.
- [Design by Contract](https://banes-lab.com/records/architecture/design-by-contract.md): A design rule that every operation states the preconditions it needs, the postconditions it guarantees and the invariants it keeps.
- [Explicit Contracts](https://banes-lab.com/records/architecture/explicit-contracts.md): A design rule that every boundary declares the shape and meaning of what crosses it in a typed contract.
- [Stable Interfaces](https://banes-lab.com/records/architecture/stable-interfaces.md): The degree to which a public interface keeps its signatures and meaning across releases.
- [Interface-Based Design](https://banes-lab.com/records/architecture/interface-based-design.md): A design rule that a module depends on interfaces, and the implementation behind each one is supplied from outside.
- [Contract-First Design](https://banes-lab.com/records/architecture/contract-first-design.md): A design rule that a boundary's contract is written and agreed before the implementation behind it.
- [Service Contract](https://banes-lab.com/records/architecture/service-contract.md): A rule or precondition that a service declares its operations, their results and their side effects to every consumer.
- [Versioning](https://banes-lab.com/records/architecture/versioning.md): A mechanism that labels each release of an interface or schema, so consumers can tell compatible changes from breaking ones.
- [Consumer-Driven Contracts](https://banes-lab.com/records/architecture/consumer-driven-contracts.md): A rule or precondition that a provider verifies each change against the expectations its consumers have recorded.
- [Centralized Configuration](https://banes-lab.com/records/architecture/centralized-configuration.md): A design pattern that keeps every service's configuration in one versioned store the services read from.
- [Decentralization](https://banes-lab.com/records/architecture/decentralization.md): A design rule that decisions and runtime control sit with the teams and services that own them, joined by contracts.
- [Testability](https://banes-lab.com/records/architecture/testability.md): The degree to which code can be tested in isolation, with its dependencies, time and randomness supplied by the test.
- [Single Responsibility Principle (SRP)](https://banes-lab.com/records/architecture/single-responsibility.md): A design rule that a class or module has one reason to change, because it serves one responsibility.
- [Low Coupling](https://banes-lab.com/records/architecture/low-coupling.md): The degree to which a module can change without forcing changes in the modules around it.
- [Abstraction](https://banes-lab.com/records/architecture/abstraction.md): A design rule that a concept is expressed by what it does for the code that uses it, and the detail of how it does it stays out of that expression.
- [Modularity](https://banes-lab.com/records/architecture/modularity.md): A design rule that a system is divided into cohesive modules with explicit boundaries and few dependencies between them.
- [Replaceability](https://banes-lab.com/records/architecture/replaceability.md): The degree to which a component can be swapped for another implementation of its interface without editing its callers.
- [Interchangeability](https://banes-lab.com/records/architecture/interchangeability.md): The degree to which several implementations conform to one contract closely enough to be selected at runtime.
- [Independence](https://banes-lab.com/records/architecture/independence.md): A design rule that a module can be tested and deployed without the modules around it being present or released.
- [Autonomy](https://banes-lab.com/records/architecture/autonomy.md): A design rule that a service or team owns its data and decisions, so it alone writes its data and others reach or change it only through its published API or events.
- [Interface Segregation Principle (ISP)](https://banes-lab.com/records/architecture/interface-segregation.md): A design rule that a client depends on an interface holding only the methods it uses.
- [Event-Driven Architecture](https://banes-lab.com/records/architecture/event-driven-architecture.md): A convention of connecting services through published events, with each consumer reacting independently of the producer.
- [Asynchronous Communication](https://banes-lab.com/records/architecture/asynchronous-communication.md): A design rule that work the caller does not need at once is sent as a message, so the caller does not wait on it.
- [Dead-Letter Queue](https://banes-lab.com/records/architecture/dead-letter-queue.md): A design pattern that moves a message which keeps failing into a separate queue, where it can be inspected and reprocessed.
- [Idempotent Consumer](https://banes-lab.com/records/architecture/idempotent-consumer.md): A design pattern in which a consumer records each message it has processed, so a redelivered message has no second effect.
- [Competing Consumers](https://banes-lab.com/records/architecture/competing-consumers.md): A design pattern in which several consumers read from one queue, and each message goes to only one of them.
- [Graceful Degradation](https://banes-lab.com/records/architecture/graceful-degradation.md): A design rule that the failure of an optional dependency removes only the feature it serves, and the rest of the system keeps working.
- [Fault Tolerance](https://banes-lab.com/records/architecture/fault-tolerance.md): The degree to which a system keeps operating correctly when some of its components fail.
- [Resilience](https://banes-lab.com/records/architecture/resilience.md): The degree to which a system contains failures, stays stable under stress and recovers.
- [Error Handling](https://banes-lab.com/records/architecture/error-handling.md): A design rule that every error is either handled with its context kept, or propagated as a typed error the caller must handle.
- [Fallback Pattern](https://banes-lab.com/records/architecture/fallback-pattern.md): A design pattern that routes a failed call to an alternate provider or response declared in advance.
- [Circuit Breaker Pattern](https://banes-lab.com/records/architecture/circuit-breaker-pattern.md): A design pattern that stops calling a dependency after repeated failures and probes it again after a wait.
- [Bulkhead Pattern](https://banes-lab.com/records/architecture/bulkhead-pattern.md): A design pattern that gives each workload its own pool of threads or connections, so one workload cannot exhaust the others.
- [Backpressure](https://banes-lab.com/records/architecture/backpressure.md): A mechanism that lets a consumer signal its capacity, so a producer slows down when the consumer falls behind.
- [Quality Attributes](https://banes-lab.com/records/architecture/quality-attributes.md): A conceptual representation of the non-functional properties a system must meet, each stated as a measurable scenario.
- [Capability Declaration](https://banes-lab.com/records/architecture/capability-declaration.md): A mechanism by which a plugin or service lists the operations it supports, so callers test the list instead of probing for methods.
- [Model Inference](https://banes-lab.com/records/architecture/model-inference.md): The ability to run a trained model on validated input at runtime and return a checked prediction or generation.
- [Observability](https://banes-lab.com/records/architecture/observability.md): The degree to which a system's internal behavior in production can be inferred from the logs, metrics and traces it emits.
- [Logging](https://banes-lab.com/records/architecture/logging.md): A mechanism that records structured events with their context as the code runs.
- [Monitoring](https://banes-lab.com/records/architecture/monitoring.md): A mechanism that collects metrics about resources and service levels over time and compares them with thresholds.
- [Alerting](https://banes-lab.com/records/architecture/alerting.md): A mechanism that notifies an on-call responder when a monitored condition holds for longer than its threshold.
- [SLO/SLI](https://banes-lab.com/records/architecture/slo-sli.md): A rule or precondition that a service's reliability is stated as a measured indicator with an objective and an error budget over a window.
- [Dashboards](https://banes-lab.com/records/architecture/dashboards.md): Descriptive data about a system's key signals, arranged as panels that show health and trends at a glance.
- [Scalability](https://banes-lab.com/records/architecture/scalability.md): The degree to which a system keeps its throughput and latency as load grows, by adding resources.
- [Horizontal Scaling](https://banes-lab.com/records/architecture/horizontal-scaling.md): A technique for adding capacity by running more stateless instances of a service behind a load balancer.
- [Load Balancing](https://banes-lab.com/records/architecture/load-balancing.md): A mechanism that spreads incoming requests across healthy instances of a service.
- [Partitioning](https://banes-lab.com/records/architecture/partitioning.md): A technique for dividing data or work into independent partitions by a key, so each can be processed in parallel.
- [Statelessness](https://banes-lab.com/records/architecture/statelessness.md): A design rule that a handler keeps no request state between calls, so any instance can serve any request.
- [Concurrency](https://banes-lab.com/records/architecture/concurrency.md): A conceptual representation of several tasks in progress over overlapping time, with their access to shared state coordinated.
- [Throughput](https://banes-lab.com/records/architecture/throughput.md): The rate at which a system completes requests, messages or items, counted per unit of time.
- [Latency](https://banes-lab.com/records/architecture/latency.md): A measure of the time between a request and its response, usually reported at percentiles.
- [Performance Engineering](https://banes-lab.com/records/architecture/performance-engineering.md): The practice of setting performance budgets, measuring against a representative workload and changing code only where a measurement points.
- [Benchmarking](https://banes-lab.com/records/architecture/benchmarking.md): The activity of timing a fixed workload repeatedly in a controlled environment, so results can be compared across changes.
- [Rate Limiting](https://banes-lab.com/records/architecture/rate-limiting.md): A mechanism that caps how many requests a caller can make in a time window and rejects the excess.
- [CDN / Edge Caching](https://banes-lab.com/records/architecture/cdn-edge-caching.md): A mechanism that serves cacheable content from servers near the requester, keyed by a fingerprint of the content.
- [Read Replica](https://banes-lab.com/records/architecture/read-replica.md): A technique for routing read queries to replicated copies of a database, so the primary handles only writes.
- [Stateless Processing](https://banes-lab.com/records/architecture/stateless-processing.md): A design rule that a processor derives each result only from its input and explicitly passed context.
- [Service Registry](https://banes-lab.com/records/architecture/service-registry.md): A mechanism where services or plugins register under a key and are resolved by that key at runtime.
- [Health Checks](https://banes-lab.com/records/architecture/health-checks.md): A mechanism that reports whether an instance and the dependencies it needs are ready to serve, so routing and restarts can act on it.
- [Failover](https://banes-lab.com/records/architecture/failover.md): A mechanism that switches traffic or reads to a standby instance when the active one fails.
- [Redundancy](https://banes-lab.com/records/architecture/redundancy.md): A mechanism that keeps spare instances or capacity for a critical component, spread across failure domains.
- [Replication](https://banes-lab.com/records/architecture/replication.md): A mechanism that keeps copies of data on several nodes under a declared consistency policy, such as a write quorum.
- [Auto-Scaling](https://banes-lab.com/records/architecture/auto-scaling.md): The ability to change the number of running instances automatically, between set bounds, from a load metric.
- [Auto-Remediation](https://banes-lab.com/records/architecture/auto-remediation.md): The ability to run a guarded, automated response, such as a restart, a reset and replay or a compaction, when an alert or a health signal shows a failure whose fix is known.
- [Graceful Shutdown](https://banes-lab.com/records/architecture/graceful-shutdown.md): A mechanism that, on a stop signal, stops accepting work, drains in-flight work and closes connections before the process exits.
- [Security by Design](https://banes-lab.com/records/architecture/security-by-design.md): A design rule that threats are modeled and controls built into every component from its first design.
- [Least Privilege](https://banes-lab.com/records/architecture/least-privilege.md): A design rule that each user, service and process holds only the permissions its task needs.
- [Attack Surface Reduction](https://banes-lab.com/records/architecture/attack-surface-reduction.md): A design rule that endpoints, ports, features and permissions nothing uses are removed or disabled.
- [Authentication](https://banes-lab.com/records/architecture/authentication.md): A mechanism that verifies a caller's claimed identity from a credential before any protected action runs.
- [CSRF Protection](https://banes-lab.com/records/architecture/csrf-protection.md): A mechanism that rejects state-changing requests which lack proof of coming from the site's own pages, such as an anti-forgery token.
- [Parameterized Queries](https://banes-lab.com/records/architecture/parameterized-queries.md): A mechanism that sends query text and values to the database separately, so values are never parsed as query syntax.
- [Session Management](https://banes-lab.com/records/architecture/session-management.md): A mechanism that keeps authenticated sessions on the server, with expiry, rotation and revocation, and gives the client only an opaque identifier.
- [Ports and Adapters Architecture](https://banes-lab.com/records/architecture/ports-and-adapters-architecture.md): A convention of placing every external dependency behind a port the application owns, implemented by an adapter outside it.
- [Hexagonal Architecture](https://banes-lab.com/records/architecture/hexagonal-architecture.md): A convention of keeping a domain core free of framework and data types, with every input and output reached through ports.
- [Microservices](https://banes-lab.com/records/architecture/microservices.md): A convention of splitting a system into services that each own their data and deploy independently.
- [Service-Oriented Architecture](https://banes-lab.com/records/architecture/service-oriented-architecture.md): A convention of exposing each business capability as a service governed by a published contract.
- [Transaction Boundary](https://banes-lab.com/records/architecture/transaction-boundary.md): A rule or precondition that a transaction covers exactly the writes of one unit of work inside one service.
- [State Isolation](https://banes-lab.com/records/architecture/state-isolation.md): A design rule that each piece of mutable state belongs to one unit of concurrent execution, so no two units that run at the same time can write it.