Skip to main content

Acronyms Reference

Quick reference guide for common software architecture acronyms including SLA/SLO/SLI, RBAC/ABAC, ADR, CQRS, DDD, OAuth, JWT, and more.

Service Level Definitions​

SLA (Service Level Agreement) A commitment made to customers about service availability and performance. Example: "99.9% availability" or "response time under 200ms for 95% of requests." SLAs are contractual commitments with consequences (refunds, credits) if violated.

SLO (Service Level Objective) Internal targets that are more aggressive than SLAs. Used to drive engineering decisions about reliability investment. If SLOs are met, SLAs are typically met. Example: "99.95% availability internally" while promising "99.9% SLA" to customers.

SLI (Service Level Indicator) Measurable metrics that represent whether SLOs are being met. Examples: availability percentage, latency percentiles, error rate. SLIs are the actual measured values tracked over time.

Example Relationship:

  • SLA: "We promise 99.9% availability (4.38 hours downtime/month allowed)"
  • SLO: "We target 99.95% availability internally"
  • SLI: "(successful requests / total requests) * 100 = 99.92% (measured value)"

Access Control & Security​

RBAC (Role-Based Access Control) Access control based on user roles. Users are assigned to roles (admin, editor, viewer), and roles have permissions. Simple to understand and implement. Doesn't work well for dynamic permissions across different domains.

Example: Admin role has all permissions, Editor role can create/edit content, Viewer role is read-only.

ABAC (Attribute-Based Access Control) Access control based on attributes of user, resource, action, and environment. More flexible and powerful than RBAC. Can express complex policies like "allow access to documents created by your department only."

Example: Access granted if (user.department == resource.department AND time < 18:00 AND user.role == "manager")

IAM (Identity and Access Management) System for managing digital identities and controlling what authenticated users can access. Includes identity verification, access granting, and audit logging.

OAuth Open standard for delegated authorization (not authentication). Allows users to authorize applications to access their data without sharing passwords. Commonly used for "Sign in with Google/GitHub."

JWT (JSON Web Token) Compact, self-contained token format for transmitting information. Contains encoded claims (user ID, permissions) and is cryptographically signed. Stateless—no server-side session storage needed.

TLS/SSL (Transport Layer Security/Secure Sockets Layer) Protocols for encrypting communication over networks. HTTPS uses TLS. TLS 1.2 and 1.3 are current standards; older SSL versions are deprecated.​

Architecture & Design Decisions​

ADR (Architecture Decision Record) Document capturing a significant technical decision, its context, rationale, and consequences. Creates searchable history of "why" decisions were made. More details

DDD (Domain-Driven Design) Approach to software design emphasizing collaboration with domain experts and modeling the business domain explicitly in code. Uses concepts like entities, value objects, aggregates, and bounded contexts.

CQRS (Command Query Responsibility Segregation) Pattern separating read (query) and write (command) models. Useful for systems where read and write patterns are very different. Enables independent scaling of read and write paths.

Event Sourcing Pattern of storing state changes as immutable events rather than current state. Enables complete audit trail, time-travel debugging, and rebuilding state at any point. Often paired with CQRS.

SOLID (Design Principles) Five principles for writing maintainable code:

  • Single Responsibility Principle: One reason to change
  • Open/Closed Principle: Open for extension, closed for modification
  • Liskov Substitution Principle: Subtypes should be substitutable
  • Interface Segregation Principle: Many specific interfaces over general
  • Dependency Inversion Principle: Depend on abstractions, not concrete implementations

API & Communication​

REST (Representational State Transfer) Architectural style for APIs using HTTP methods (GET, POST, PUT, DELETE) on resources (URIs). Stateless, cacheable, and widely used. Standard way to design web APIs.

gRPC (Google Remote Procedure Call) High-performance RPC framework using Protocol Buffers and HTTP/2. Supports streaming, multiplexing, and binary serialization. Good for service-to-service communication.

HATEOAS (Hypermedia As The Engine Of Application State) REST principle where API responses include links to related resources and possible actions. Enables client discovery of available operations without hardcoding URLs.

API Versioning Strategies:

  • URL path: /api/v1/users and /api/v2/users
  • Header: Accept: application/vnd.company.v1+json
  • Query parameter: /api/users?version=2

Performance & Reliability​

MTTR (Mean Time To Recovery) Average time to recover from failure. Used to measure operational efficiency. Lower is better. Related to incident response procedures and automation.

MTTF (Mean Time To Failure) Average time before system experiences a failure. Used for reliability engineering. Higher is better.

MTBF (Mean Time Between Failures) Average time between failures in a repairable system. Reliability metric: (MTTF + MTTR) / number of failures.

CDN (Content Delivery Network) Network of geographically distributed servers caching and delivering content. Reduces latency by serving content from edge servers near users. Examples: CloudFront, Akamai, Cloudflare.

TTL (Time To Live) Duration before cached content expires and must be refreshed. Set in HTTP Cache-Control headers. Shorter TTL = fresher content but more cache misses.

RPO (Recovery Point Objective) Maximum acceptable data loss (time-wise). If RPO is 1 hour, you're willing to lose up to 1 hour of data. Drives backup frequency decisions.

RTO (Recovery Time Objective) Maximum acceptable downtime. If RTO is 4 hours, you must recover within 4 hours of failure. Drives redundancy and failover automation decisions.​

Databases & Data​

ACID (Atomicity, Consistency, Isolation, Durability) Properties guaranteeing reliable transactions:

  • Atomicity: All or nothing
  • Consistency: Valid state before and after
  • Isolation: Transactions don't interfere
  • Durability: Committed data survives failures

Supported by relational databases; not guaranteed in many NoSQL databases.

CAP Theorem (Consistency, Availability, Partition tolerance) Theorem stating distributed systems can guarantee at most two of three properties. Most production systems are AP (available, partition-tolerant) over C, accepting eventual consistency.

Eventual Consistency Guarantee that system will reach consistent state eventually, even if not immediately. Used in distributed systems to trade immediate consistency for availability and partition tolerance.

Sharding Horizontal data partitioning strategy distributing data across multiple databases. Improves write scalability and query performance on large datasets. Requires application-level routing logic.

Replication Copying data across multiple servers for redundancy, read scaling, and disaster recovery. Can be synchronous (strong consistency, higher latency) or asynchronous (lower latency, eventual consistency).​

Containerization & Orchestration​

K8s (Kubernetes) Container orchestration platform automating deployment, scaling, and management of containerized applications. Declarative configuration, self-healing, and rolling updates.

Container Lightweight, isolated runtime environment packaging application code and dependencies (OS libraries, runtimes). Docker is most popular container format.

CI/CD (Continuous Integration / Continuous Deployment)

  • CI: Automatically building and testing code on every commit
  • CD: Automatically deploying passing builds to production

Reduces deployment friction and enables rapid iteration.

IaC (Infrastructure as Code) Managing infrastructure through code (Terraform, Ansible, CloudFormation). Enables version control, reproducibility, and automation of infrastructure changes.​

Network & Security​

VPC (Virtual Private Cloud) Isolated network within cloud provider. Enables private communication between resources and control over network topology, subnets, and access rules.

NAT (Network Address Translation) Technique translating private IP addresses to public ones for outbound connections. Enables private instances to communicate with internet without exposing internal addresses.

DDoS (Distributed Denial of Service) Attack sending massive traffic from multiple sources to overwhelm target. Mitigated by rate limiting, WAF (Web Application Firewall), and DDoS protection services.

WAF (Web Application Firewall) Security tool filtering and blocking malicious HTTP requests. Protects against injection attacks, XSS, CSRF, and known vulnerabilities. Often deployed in front of applications.​

Monitoring & Observability​

Observability Ability to understand system state from external outputs (logs, metrics, traces). "You can't monitor what you don't understand, but you can observe it."

Three Pillars of Observability:

  1. Metrics: Quantitative measurements (latency, error rate, throughput)
  2. Logs: Detailed event records with full context
  3. Traces: End-to-end request flows through distributed systems

Prometheus Time-series metrics database and monitoring platform. Scrapes metrics from applications, stores them, and enables querying and alerting.

Grafana Visualization and dashboarding platform for metrics data. Creates beautiful dashboards from Prometheus and other data sources.

APM (Application Performance Monitoring) Tools tracking application performance (latency, errors, resource usage). Examples: New Relic, Datadog, Dynatrace.​

Testing​

TDD (Test-Driven Development) Development practice: write test first, then code to pass test. Encourages simple design and comprehensive test coverage.

BDD (Behavior-Driven Development) Testing approach using human-readable scenario descriptions (Given-When-Then format). Bridges gap between technical and non-technical stakeholders.

A/B Testing Experiment comparing two variants (A and B) with real users to measure which performs better. Common in UI/UX decisions.​

Useful References​

For detailed examples and implementation guidance, see: