15 Key Terms in Software Architecture Everyone Should Know
Introduction
Software architecture describes the high-level structure of a system and the major decisions that shape how its parts work together. Components, services, APIs, databases, caches, messaging systems, deployment models, scalability, resilience, and observability can all influence an application’s architecture. These 15 terms provide a practical foundation for understanding how modern software systems are organized and how architectural components interact to support larger system requirements.
1. Software Architecture
Software architecture is the high-level structure of a software system and the important decisions that shape it. Architecture describes major components, responsibilities, interactions, deployment boundaries, and quality goals. It focuses on decisions that are costly to change later.
For example, an e-commerce architecture may separate web UI, APIs, order services, databases, messaging, and external payment systems.
2. Component
A component is a distinct part of a system with a defined responsibility and interface. Components may be modules, services, libraries, or deployable units. Clear component boundaries help teams reason about ownership and change.
For example, an Order component can manage order creation and status while relying on a separate Payment component.
3. Interface
An interface defines how architectural components communicate. Interfaces can be APIs, events, function contracts, or protocols. Stable, clear interfaces reduce the need for one component to know another component’s internal details.
For example, a REST API can define how the frontend retrieves product information from a catalog service.
4. Layered Architecture
Layered architecture organizes software into levels with different responsibilities. Typical layers include presentation, business logic, and data access. Layers can improve separation of concerns, although too many layers can add unnecessary indirection.
For example, a web request can move from controller to service to repository to database.
5. Monolith
A monolith is an application deployed primarily as one unit. Its modules may be well separated internally, but they are built and released together. Monoliths can be simpler to develop and operate, especially when system scale and team structure do not require distributed services.
For example, a business application may contain catalog, orders, and billing modules in one deployable application.
6. Microservices
Microservices are independently deployable services organized around focused business capabilities. Each service owns a bounded responsibility and communicates through APIs or messaging. This can improve independent delivery but adds distributed-system complexity.
For example, order, inventory, and payment may run as separate services with independent deployments.
7. API Gateway
An API gateway is an entry point that routes client requests to backend services. It can centralize routing, authentication, rate limiting, protocol handling, and other cross-cutting concerns. It should not become a place where all business logic accumulates.
Get Bishal Goutam’s stories in your inbox
Join Medium for free to get updates from this writer.
For example, a mobile app can call one gateway that routes product requests to catalog and account requests to identity services.
8. Event-Driven Architecture
Event-driven architecture connects components through events that describe things that happened. Producers publish events without needing every consumer to respond immediately. Consumers process events independently, supporting loose coupling and asynchronous workflows.
For example, an OrderPlaced event can trigger inventory reservation, email, and analytics consumers.
9. Message Broker
A message broker receives and distributes messages or events between systems. Brokers provide queues, topics, delivery controls, and buffering. They help decouple producers from consumers and absorb temporary differences in processing speed.
For example, a payment service can publish an event to a broker that several downstream services consume.
10. Cache
A cache stores frequently used data closer to consumers to reduce repeated expensive work. Architectures use caches to reduce database load and improve latency. Cache freshness, invalidation, and failure behavior must be considered.
For example, a product catalog can cache popular product details instead of querying the database for every request.
11. Scalability
Scalability is a system’s ability to handle increased work by using resources effectively. Architectures may scale vertically by using larger machines or horizontally by adding instances. State management, data stores, and bottlenecks determine how far scaling can go.
For example, a stateless API can often scale horizontally by adding more instances behind a load balancer.
12. Availability
Availability is the degree to which a system is accessible and able to provide its service when needed. Architectures improve availability through redundancy, failover, health checks, fault isolation, and careful dependency design. Availability targets should reflect business needs.
For example, running service instances across multiple failure zones can reduce the impact of one zone becoming unavailable.
13. Resilience
Resilience is a system’s ability to continue useful operation and recover when failures occur. Timeouts, retries with limits, circuit breakers, redundancy, queues, and graceful degradation are common resilience techniques. The goal is to prevent one failure from spreading unnecessarily.
For example, if a recommendation service fails, a store may still show products without personalized recommendations.
14. Data Ownership
Data ownership defines which component or domain is responsible for a particular set of data. Clear ownership reduces conflicting updates and hidden coupling. In distributed systems, other components often access owned data through APIs or events rather than directly modifying the same database tables.
For example, an Account service may own customer profile data while Order services keep only the customer reference they need.
15. Observability
Observability is the architectural capability to understand system behavior from telemetry. Distributed architectures need consistent metrics, logs, traces, correlation identifiers, and health information. Observability helps teams diagnose interactions that cross many services.
For example, a trace can show that a slow checkout spent most of its time waiting for an external payment provider.
