Skip to content

Architecture Decision Records (ADRs)

This directory contains Architecture Decision Records (ADRs) for the SPOT platform.

What are ADRs?

Architecture Decision Records document important architectural decisions made during the project, including:

  • The context and problem being addressed
  • The decision that was made
  • The rationale behind the decision
  • Consequences (both positive and negative)
  • Alternatives that were considered

Why ADRs?

ADRs help us:

  • Understand why decisions were made
  • Avoid rehashing old discussions
  • Onboard new team members faster
  • Make better decisions by learning from past ones
  • Maintain institutional knowledge

ADR Format

Each ADR follows the template defined in TEMPLATE.md and includes:

  • Title and metadata (date, status, deciders)
  • Context describing the problem
  • The decision that was made
  • Rationale explaining why
  • Consequences (positive and negative)
  • Alternatives considered and why they were rejected
  • Implementation notes
  • References

ADR Status

  • Proposed: Under discussion, not yet decided
  • Accepted: Decision has been made and is being implemented
  • Deprecated: No longer relevant but kept for historical context
  • Superseded: Replaced by a newer ADR (link to the new one)

Index of ADRs

Number Title Status Date
001 Microservices Architecture Accepted 2025-11-04
002 RabbitMQ for Inter-Service Messaging Accepted 2025-11-04
003 Pydantic for Data Validation Accepted 2025-11-04
004 Separate Analyzer Repositories Accepted 2025-11-04
005 spot-sdk Shared Package Accepted 2025-11-04

Creating a New ADR

  1. Copy template.md to a new file: NNN-short-title.md (use next number)
  2. Fill in all sections with relevant information
  3. Update the index table above
  4. Submit for review via pull request
  5. Once approved, change status to "Accepted"

Guidelines

  • Be specific: Avoid vague statements
  • Be concise: Focus on the decision, not implementation details
  • Be honest: Document both pros and cons
  • Be complete: Include all alternatives considered
  • Be timely: Write ADRs when decisions are made, not months later

References