Skip to content

ADR-0004: Adopt Event-Driven Integration

  • Status: Accepted
  • Date: 2026-10-08
  • Decision Owners: Zelvoryqa Architecture
  • Technical Area: Event-Driven Architecture / Distributed Systems
  • Related ADRs:
  • ADR-0001: Adopt Microservices Based on Business Capabilities
  • ADR-0002: Adopt Multi-Tenant SaaS Architecture
  • ADR-0003: Define Service Data Ownership and Tenant Data Isolation

Context

Zelvoryqa is designed as a multi-tenant SaaS platform composed of independently deployable services aligned to business capabilities.

ADR-0001 establishes that services own their business capabilities and communicate through explicit integration boundaries.

ADR-0002 establishes that one organization corresponds to one logical tenant boundary and that organization context must be preserved across distributed operations.

ADR-0003 establishes that services own their operational data, that direct cross-service database access is prohibited, and that services may maintain derived representations of information originating from other services without becoming authoritative for the source data.

These decisions require a communication model that allows services to coordinate business workflows without introducing unnecessary synchronous dependencies or violating service and tenant boundaries.

Zelvoryqa must support workflows involving multiple services, including:

  • Order creation and inventory reservation
  • Purchasing and inventory replenishment
  • Warehouse operations and fulfillment
  • Shipping and delivery updates
  • Operational notifications
  • Real-time operational visibility
  • Analytical projections and reporting
  • Forecasting and optimization

For example, creating an order may require the Inventory Service to reserve inventory, the Fulfillment Service to prepare fulfillment work, and Operations Intelligence to update analytical projections.

Requiring the Order Service to directly coordinate every downstream activity would increase coupling and make the availability of unrelated services part of the order creation workflow.

Without explicit asynchronous integration rules, Zelvoryqa risks:

  • Tight coupling between business services
  • Cascading failures caused by synchronous dependencies
  • Inconsistent event ownership
  • Duplicate event processing
  • Lost business events
  • Unbounded retries
  • Incorrect assumptions about event ordering
  • Inconsistent derived data
  • Cross-tenant event processing
  • Difficult event contract evolution
  • Limited operational visibility into asynchronous workflows

Zelvoryqa therefore requires a consistent event-driven integration model that preserves business ownership, tenant isolation, reliability, and independent service evolution.

Decision

Zelvoryqa will adopt event-driven integration as a primary mechanism for asynchronous communication between independently deployable services.

Services will publish business events representing meaningful facts or state changes within their owned business capabilities.

Interested services may independently subscribe to and process those events when relevant to their responsibilities.

Event-driven integration will complement, rather than replace, synchronous service communication.

The architecture will establish explicit rules for:

  • Event ownership
  • Event producers and consumers
  • Business event contracts
  • Organization context propagation
  • Event publication reliability
  • Delivery and processing semantics
  • Idempotent processing
  • Retry and failure handling
  • Dead-letter handling
  • Event ordering
  • Eventual consistency
  • Observability
  • Event contract evolution

The exact messaging technology, subject or topic structure, event envelope, and implementation mechanisms will be defined through subsequent implementation decisions.

Business Events Represent Owned Facts

A business event represents a meaningful fact that has occurred within a service's business capability.

Examples include:

  • OrderCreated
  • OrderCancelled
  • InventoryReserved
  • InventoryReservationFailed
  • InventoryReceived
  • PurchaseOrderCreated
  • FulfillmentCompleted
  • ShipmentDispatched
  • ShipmentDelivered

An event describes something that has happened rather than instructing an unrelated service to execute a specific internal operation.

For example:

OrderCreated represents the fact that the Order Service created an order.

The Order Service does not need to know which downstream services will consume that event.

Events must represent committed or otherwise explicitly defined business state transitions. Consumers must not be informed that a durable business change occurred when that change was not successfully committed.

Event Producers Own Their Events

The service responsible for a business capability owns the business events representing changes within that capability.

For example:

Order Service
    |
    +---- OrderCreated
    +---- OrderCancelled

Inventory Service
    |
    +---- InventoryReserved
    +---- InventoryReservationFailed

Shipping Service
    |
    +---- ShipmentDispatched
    +---- ShipmentDelivered

The owning service is responsible for:

  • Defining the meaning of its events
  • Establishing event contracts
  • Publishing events for relevant business state changes
  • Preserving required organization context
  • Maintaining event compatibility according to versioning policies
  • Providing sufficient information for consumers to interpret events
  • Avoiding disclosure of unauthorized or unnecessary data

Event ownership follows business capability ownership.

A service must not publish events claiming authority over another service's business state.

Event Consumers Operate Independently

A service may consume events originating from another service when those events are relevant to its own business capability.

A service may act as both an event producer and an event consumer.

Conceptually:

Order Service
     |
     | publishes OrderCreated
     v
Event Bus
     |
     +----> Inventory Service
     |
     +----> Fulfillment Service
     |
     +----> Notification Service
     |
     +----> Operations Intelligence

The diagram illustrates potential subscribers, not a requirement that every service consume every event.

Each consumer independently determines whether an event is relevant to its responsibilities.

The Inventory Service may consume order events to initiate inventory reservation.

The Fulfillment Service may consume relevant order and inventory events to coordinate fulfillment.

The Notification Service may consume events to produce notifications.

Operations Intelligence may consume events across multiple business capabilities to maintain analytical projections and generate operational insights.

Consumers must not depend on producers knowing their identities or implementation details.

Services May Produce and Consume Events

A service may consume an event, perform business logic within its own capability, and publish a new event describing the resulting state change.

For example:

Order Service
     |
     | OrderCreated
     v
Event Bus
     |
     v
Inventory Service
     |
     | Reserve inventory
     |
     | InventoryReserved
     v
Event Bus
     |
     +----> Order Service
     |
     +----> Fulfillment Service
     |
     +----> Operations Intelligence

The Inventory Service owns the inventory reservation operation and the resulting InventoryReserved event.

The Order Service remains authoritative for the order.

The Fulfillment Service remains authoritative for fulfillment state.

Consuming an event does not transfer ownership of the originating service's operational data.

Events Must Have Explicit Contracts

Business events must have documented contracts describing their meaning and the information required by consumers.

Event contracts must provide sufficient information to support:

  • Event identification
  • Event type identification
  • Producer identification
  • Event occurrence information
  • Schema or contract versioning
  • Organization context when applicable
  • Correlation across distributed workflows
  • Event-specific business data

Conceptually:

Business Event
     |
     +---- Event ID
     +---- Event Type
     +---- Producer
     +---- Organization Context
     +---- Occurred At
     +---- Contract Version
     +---- Correlation Information
     +---- Event Data

This represents conceptual event information rather than a required serialization format or exact event envelope.

Event contracts must avoid unnecessary coupling to internal database schemas and implementation details.

Events must expose business information through intentional contracts rather than unrestricted replication of internal service state.

Organization Context Must Be Preserved

Organization-scoped events must preserve sufficient organization context to enforce tenant isolation throughout asynchronous processing.

Conceptually:

OrderCreated
    |
    +---- Organization A
    |
    v
Event Bus
    |
    v
Inventory Consumer
    |
    v
Organization A Context
    |
    v
Organization A Inventory

Event consumers must establish and validate the appropriate execution context before accessing organization-owned resources.

An organization identifier carried in an event identifies the organization but does not automatically establish trusted or authorized organization context.

Consumers must apply the trust and authorization requirements appropriate to the event source, workload identity, operation, and resource ownership.

Organization-scoped events with missing, invalid, or untrusted required context must not be processed as unrestricted platform-level events.

Tenant isolation must remain intact across:

  • Event publication
  • Event delivery
  • Consumer execution
  • Derived data creation
  • Retries
  • Replay
  • Dead-letter processing
  • Background workflows
  • Analytical processing

Platform-level events must be explicitly identified and handled through separately authorized capabilities.

Event Publication Must Be Reliable

A service must not silently lose a required business event after successfully committing the corresponding business state change.

The architecture must account for failures occurring between operational data persistence and event publication.

For example:

Order Service
     |
     v
Commit Order
     |
     X  Process crashes
     |
     v
Publish OrderCreated

Without a reliability mechanism, the order may exist while downstream consumers never receive the event.

Implementations must provide a defined mechanism for reliable publication of required business events.

Possible approaches include transactional outbox patterns, durable publication workflows, or equivalent mechanisms that address the consistency boundary between business state changes and event publication.

The exact mechanism will depend on the selected persistence and messaging technologies.

The architecture must not assume that writing operational data and publishing to a separate messaging system form one atomic transaction.

Delivery and Processing Semantics

Zelvoryqa will design event consumers to tolerate at-least-once delivery.

An event may be delivered or processed more than once.

Consumers must not assume that each event is delivered exactly once.

For example:

Event Bus
    |
    | OrderCreated
    v
Inventory Consumer
    |
    | Processes event
    |
    X Acknowledgment fails
    |
    v
Event delivered again

The Inventory Service must prevent duplicate delivery from creating duplicate inventory reservations.

Consumers must provide idempotent processing behavior for operations that could otherwise produce incorrect repeated effects.

The messaging implementation must provide a documented delivery and acknowledgment model consistent with these requirements.

End-to-end exactly-once business processing is not assumed.

Idempotent Event Processing

Consumers must handle repeated delivery of the same event without unintentionally repeating business effects.

Possible mechanisms include:

  • Processed-event tracking
  • Event identifiers
  • Business idempotency keys
  • Conditional state transitions
  • Uniqueness constraints
  • Transactional processing safeguards

For example:

OrderCreated
    |
    v
Inventory Consumer
    |
    +---- First delivery
    |         |
    |         v
    |    Reserve inventory
    |
    +---- Duplicate delivery
              |
              v
         No duplicate reservation

The chosen mechanism must account for failures between applying a business change and acknowledging the event.

Where a consumer records deduplication state and modifies operational data, the implementation must preserve consistency between those changes.

Idempotency requirements apply to downstream side effects as well as local database writes.

Retry and Failure Handling

Transient failures during event processing must be handled through bounded, controlled retry policies.

Retry behavior must consider:

  • Failure classification
  • Retryable versus non-retryable errors
  • Backoff
  • Maximum attempts or elapsed time
  • Resource consumption
  • Consumer availability
  • Dependency failures
  • Tenant isolation
  • Operational visibility

Retries must not create uncontrolled processing loops or overwhelm unavailable dependencies.

Failures caused by invalid contracts, missing required organization context, or authorization violations must not be treated as ordinary transient failures.

Retry policies must preserve event identity and organization scope.

Dead-Letter Handling

Events that cannot be processed successfully within the defined retry policy must have an explicit failure-handling path.

This may include a dead-letter queue, dead-letter stream, quarantine mechanism, or equivalent durable failure record.

Conceptually:

Event Bus
    |
    v
Event Consumer
    |
    +---- Success
    |
    +---- Retryable Failure
    |         |
    |         v
    |       Retry
    |
    +---- Terminal Failure
              |
              v
        Dead-Letter Handling

Dead-letter handling must support:

  • Identification of failed events
  • Failure reason visibility
  • Appropriate operational investigation
  • Controlled replay or reprocessing
  • Preservation of organization context
  • Prevention of unauthorized cross-tenant access
  • Retention and cleanup policies

Dead-letter handling must not automatically grant operators or consumers unrestricted access to tenant-owned event data.

The exact dead-letter mechanism will be selected with the messaging implementation.

Event Ordering Must Be Explicit

Zelvoryqa must not assume global ordering across all events, producers, or services.

Ordering requirements must be established according to business workflows.

For example, a consumer processing events related to one order may need to account for:

OrderCreated
     |
     v
OrderUpdated
     |
     v
OrderCancelled

However, delivery order may differ because of concurrency, retries, multiple publishers, or messaging infrastructure behavior.

Consumers must not assume that events are processed in business-state order unless the relevant contract and infrastructure explicitly provide the necessary ordering guarantees.

Possible approaches include:

  • Ordering within a defined aggregate or partition
  • Entity version information
  • Sequence information
  • Conditional updates
  • State reconciliation
  • Re-fetching authoritative state when necessary

The ordering scope and mechanisms will be determined by the requirements of individual workflows.

Eventual Consistency Is Expected

Asynchronous communication introduces eventual consistency between services and their derived representations.

For example:

Order Service
     |
     | OrderCreated
     v
Event Bus
     |
     v
Operations Intelligence
     |
     v
Order Analytical Projection

The Order Service may commit an order before Operations Intelligence processes the corresponding event.

During that interval, the analytical projection may temporarily lag behind the authoritative operational state.

Services must account for this behavior when designing workflows, APIs, and user experiences.

Eventual consistency must not be used as justification for violating critical business invariants.

Operations requiring an immediate authoritative result may require synchronous communication or an explicitly coordinated workflow.

Eventual consistency must also be considered when designing recovery, reconciliation, and data-correction mechanisms.

Event-Driven Workflows Must Respect Service Ownership

Events may coordinate workflows spanning multiple business capabilities.

However, a consuming service must not directly modify operational data owned by another service.

For example:

OrderCreated
     |
     v
Inventory Service
     |
     v
Inventory Reservation
     |
     v
InventoryReserved

The Inventory Service performs inventory reservation because inventory is its owned capability.

The Order Service may react to the resulting event and update its own order state.

Cross-service workflows must respect the authoritative ownership established by ADR-0003.

Distributed workflows requiring compensation, orchestration, or complex state coordination may require additional architectural patterns.

This ADR does not require all distributed workflows to use choreography or prohibit explicit orchestration when justified.

Derived Data and Analytical Consumers

Event consumers may maintain derived representations of information originating from other services when necessary for their own responsibilities.

Examples include:

  • Local read models
  • Event-derived state
  • Analytical projections
  • Search indexes
  • Cached representations
  • Reporting models

Derived representations must preserve the organization boundary of their source data.

They must not become authoritative for operational data owned by another service.

Operations Intelligence is expected to consume events across multiple business capabilities because cross-domain visibility and analysis are part of its responsibilities.

Other business services may consume events selectively according to their own business capabilities.

Event Contract Evolution

Event contracts must support controlled evolution without requiring all producers and consumers to deploy simultaneously.

Changes must account for:

  • Existing consumers
  • Backward compatibility
  • Schema versions
  • Required versus optional fields
  • Event meaning
  • Consumer migration
  • Historical event replay
  • Deprecation

Breaking changes must be introduced through an explicitly managed compatibility or versioning strategy.

The detailed event versioning policy will be established by a later architectural decision.

Observability and Traceability

Event-driven workflows must provide sufficient observability to investigate asynchronous processing across service boundaries.

Operational visibility should support questions such as:

  • Which service published an event?
  • Which consumers received or processed it?
  • Did processing succeed?
  • Was the event retried?
  • Was the event dead-lettered?
  • Which business operation caused the event?
  • Which organization did the operation belong to?
  • Is a consumer falling behind?
  • Are derived projections stale?

Observability may include:

  • Structured logs
  • Distributed traces
  • Event and correlation identifiers
  • Consumer processing metrics
  • Retry and failure metrics
  • Consumer lag or backlog metrics
  • Dead-letter monitoring
  • Event publication failures

Organization context must be available where appropriate for tenant-aware investigation without exposing unauthorized tenant data.

Organization identifiers must be used cautiously as metric labels because unbounded organization-level dimensions may create excessive metric cardinality.

The detailed observability implementation will be defined separately.

Rationale

Reduced Synchronous Coupling

Event producers do not need direct knowledge of every downstream consumer.

This allows new consumers to be introduced without modifying the producer's business workflow.

Independent Service Evolution

Services can independently implement event consumers and maintain derived representations without directly accessing another service's operational database.

Improved Failure Isolation

Asynchronous communication can reduce immediate dependencies on downstream service availability.

Durable event delivery and controlled retry behavior can allow consumers to recover from temporary failures.

This does not eliminate the need for failure handling, capacity management, or monitoring.

Support for Distributed Business Workflows

Business events provide a natural mechanism for coordinating operations across orders, inventory, fulfillment, purchasing, shipping, and notifications.

Support for Operations Intelligence

Operations Intelligence can consume events from multiple business domains without requiring every operational service to synchronously call the intelligence capability.

This supports operational visibility, analytical projections, forecasting, optimization, and future AI-assisted capabilities.

Preservation of Service Ownership

Event producers publish facts about business capabilities they own.

Consumers react within their own boundaries rather than directly modifying the producer's operational data.

Support for Multi-Tenant SaaS Operations

Organization-aware event contracts and consumer processing preserve tenant isolation across asynchronous boundaries.

Extensibility

Future integrations, analytical consumers, and additional business capabilities can subscribe to existing events when their contracts and authorization requirements permit it.

Alternatives Considered

Alternative 1: Synchronous Service Communication Only

Services communicate exclusively through direct API or RPC calls.

Advantages

  • Immediate responses
  • Straightforward request-response flow
  • Easier reasoning about some operations
  • No separate messaging infrastructure

Disadvantages

  • Greater runtime coupling
  • Increased risk of cascading failures
  • Downstream availability affects upstream workflows
  • More difficult integration of multiple independent consumers
  • Less natural support for asynchronous analytics

Reason Not Selected

Synchronous communication alone does not provide the decoupling and asynchronous workflow capabilities required by Zelvoryqa.

It remains appropriate for operations requiring immediate responses or authoritative reads.

Alternative 2: Shared Database Integration

Services coordinate by reading and writing shared operational tables.

Advantages

  • Simple initial data sharing
  • Direct queries across domains
  • No event infrastructure required

Disadvantages

  • Violates service data ownership
  • Couples services to internal database schemas
  • Weakens independent deployment
  • Risks bypassing business invariants
  • Complicates tenant isolation

Reason Not Selected

This conflicts with ADR-0001 and ADR-0003.

Alternative 3: Centralized Orchestrator for All Cross-Service Workflows

A central component directly coordinates every interaction between business services.

Advantages

  • Centralized workflow visibility
  • Explicit coordination
  • Potentially simpler management of some complex processes

Disadvantages

  • Central coordination bottleneck
  • Greater coupling to individual business workflows
  • Increased dependency on orchestrator availability
  • Unnecessary complexity for simple event-driven reactions

Reason Not Selected

Requiring centralized orchestration for every workflow would undermine service autonomy.

Explicit orchestration may still be appropriate for selected workflows requiring coordinated state transitions or compensation.

Alternative 4: Event-Driven Integration with Selective Synchronous Communication

Services publish business events for asynchronous coordination while retaining synchronous APIs where immediate interaction is required.

Advantages

  • Loose coupling
  • Independent consumers
  • Better support for asynchronous workflows
  • Supports derived data and analytics
  • Reduces some availability dependencies
  • Preserves authoritative service boundaries
  • Supports incremental extension

Disadvantages

  • Eventual consistency
  • Duplicate delivery
  • More complex debugging
  • Retry and dead-letter management
  • Event contract governance
  • Additional infrastructure
  • More complex integration testing

Reason Selected

This approach provides the best balance between service autonomy, resilience, distributed workflow support, and operational flexibility.

Consequences

Positive Consequences

  • Business services communicate through explicit asynchronous contracts.
  • Producers are decoupled from individual consumers.
  • Multiple consumers can react independently to the same business event.
  • Services retain authority over their own operational data.
  • Operations Intelligence can consume cross-domain events.
  • New integrations can be added without modifying every producer.
  • Durable messaging can support recovery from temporary consumer failures.
  • Organization-aware event processing supports tenant isolation.

Negative Consequences

  • Distributed workflows become eventually consistent.
  • Consumers require idempotency and failure handling.
  • Event publication reliability requires additional mechanisms.
  • Event contract evolution requires governance.
  • Operational debugging spans multiple asynchronous components.
  • Event infrastructure introduces operational overhead.
  • Derived projections may lag behind authoritative data.
  • Some workflows require reconciliation or compensation.

Risks

  • Business state changes may be committed without their required events being published.
  • Duplicate delivery may cause repeated business effects.
  • Consumers may process events out of order.
  • Event contracts may become tightly coupled to internal data models.
  • Consumers may fall behind.
  • Poison messages may block processing.
  • Retry storms may overwhelm dependencies.
  • Dead-letter queues may accumulate unprocessed events.
  • Derived data may become stale or inconsistent.
  • Missing organization context may create cross-tenant exposure.
  • Event payloads may disclose unnecessary sensitive information.
  • Replay may repeat previously completed side effects.
  • Uncontrolled event retention may create storage and compliance concerns.
  • Cross-service workflows may become difficult to reason about without clear ownership.

Implementation Considerations

Future implementation must define:

  • Messaging technology
  • Event transport and serialization
  • Event naming conventions
  • Event envelope structure
  • Event identifiers
  • Producer identification
  • Organization context representation and validation
  • Correlation and causation information
  • Topic or subject organization
  • Subscription and consumer configuration
  • Event publication reliability mechanisms
  • Delivery and acknowledgment behavior
  • Idempotency implementation
  • Retry and backoff policies
  • Dead-letter mechanisms
  • Ordering requirements
  • Event retention
  • Replay and reprocessing
  • Event schema evolution
  • Consumer concurrency
  • Consumer lag monitoring
  • Contract testing
  • Event security and access controls

Implementation must preserve the architectural requirements established by this ADR without assuming that every business workflow requires the same delivery, ordering, or consistency mechanisms.

Operational Considerations

Messaging infrastructure must be monitored for availability, capacity, delivery failures, and processing backlogs.

Operational systems should support investigation of event publication, delivery, processing, retries, and terminal failures.

Consumers must have documented recovery and replay procedures.

Dead-letter handling must support controlled investigation and reprocessing.

Event retention and replay policies must account for organization data retention and deletion requirements.

Tenant isolation must remain intact during operational recovery, event replay, and incident response.

Platform operators may require privileged access for diagnosing messaging failures.

Such access must be explicitly authorized and auditable rather than implemented as an implicit tenant bypass.

Capacity planning must account for:

  • Event throughput
  • Consumer concurrency
  • Processing latency
  • Backlog growth
  • Storage retention
  • Retry volume
  • Organization workload differences
  • Noisy-neighbor behavior
  • Tenant fairness

Operational monitoring should distinguish messaging infrastructure health from business workflow correctness.

A healthy event bus does not necessarily mean that consumers are processing events correctly or that business workflows are completing successfully.

Validation

This decision will be considered successfully implemented when Zelvoryqa can demonstrate that:

  • Services publish business events for meaningful state changes within their owned capabilities.
  • Event producers do not require direct knowledge of individual consumers.
  • Multiple independent consumers can process the same business event.
  • Services can act as both event producers and consumers.
  • Consumers do not gain authority over source operational data.
  • Required events are not silently lost after their corresponding business changes are committed.
  • Consumers correctly handle duplicate event delivery.
  • Duplicate events do not cause unintended duplicate business effects.
  • Transient processing failures can be retried safely.
  • Non-retryable failures follow a defined failure-handling path.
  • Events exceeding retry policies can be investigated and reprocessed through controlled mechanisms.
  • Event processing does not rely on unspecified global ordering guarantees.
  • Consumers handle eventual consistency appropriately.
  • Organization-scoped events preserve required organization context.
  • Consumers validate and enforce the appropriate organization boundary.
  • Missing or invalid organization context does not grant unrestricted access.
  • Organization A's events cannot cause unauthorized access to Organization B's resources.
  • Background processing and event replay preserve tenant isolation.
  • Derived projections preserve organization ownership.
  • Event contracts can evolve through a documented compatibility process.
  • Publication and consumer failures are observable.
  • Event-driven workflows can be traced across relevant service boundaries.
  • Consumer backlog and processing failures can be detected.
  • Automated tests cover duplicate delivery, failure recovery, and cross-tenant processing.

Follow-Up

The following architectural decisions build on this ADR:

  • ADR-0005: Define Synchronous Service Communication
  • ADR-0006: Define Authentication, Organization Membership, and Authorization
  • ADR-0007: Define API Gateway and External API Architecture

Additional later decisions will define:

  • Messaging technology and infrastructure
  • API and event contract versioning
  • Service reliability and resilience patterns
  • Observability architecture
  • CI/CD and contract testing
  • Operations Intelligence data architecture
  • Audit logging
  • Rate limiting, quotas, and tenant fairness
  • Analytics and AI isolation requirements

References

  • ADR-0001: Adopt Microservices Based on Business Capabilities
  • ADR-0002: Adopt Multi-Tenant SaaS Architecture
  • ADR-0003: Define Service Data Ownership and Tenant Data Isolation
  • Zelvoryqa Architecture Overview
  • Zelvoryqa Product Vision
  • Zelvoryqa Goals

Status Definitions

  • Proposed — The decision is under review.
  • Accepted — The decision has been approved and should guide implementation.
  • Deprecated — The decision is no longer recommended but remains for historical context.
  • Superseded — The decision has been replaced by a newer ADR.

ADR Guidelines

This ADR records one significant architectural decision.

The ADR should:

  • Explain the context that required the decision.
  • State the decision clearly.
  • Document the reasoning behind the decision.
  • Record meaningful alternatives and tradeoffs.
  • Separate durable architectural requirements from implementation details.
  • Avoid selecting technologies that belong in later decisions.
  • Be superseded rather than rewritten when the architectural decision fundamentally changes.