Understand Software Architecture visually

The basic structure that separates requesters from processors

Client-Server splits the system into a side that shows and collects input (the client) and a side that stores data and enforces rules (the server). Because multiple clients share one server, the source of truth and access control converge in a single place while each client focuses only on presentation and interaction.

A structure that reduces complexity by dividing internal responsibilities into layers

Layered Architecture organizes the inside of a single application into responsibility-based layers: presentation, use-case flow, domain rules, and technical integration. Each layer answers only its own kind of question and talks only to the layer directly below it. That separation makes it cheaper to locate where a change belongs when something needs to be modified.

An application that moves as one codebase and one deployment unit

Monolith is an application structure that bundles all features into one process and one deployment unit. No matter how many modules exist inside, the build produces a single artifact and every release moves the whole system at once. That keeps local development and debugging simple early on, but ties every change to the same deployment path as the system grows.

A structure that splits a system into independently operated service boundaries

Microservices split a system into multiple services where each one owns its own domain data and deploys independently. Services collaborate over the network through APIs or events, and each team can change and release its service at its own pace.

A common front door placed in front of many backend services

API Gateway sits as a single entry layer in front of multiple backend services, receiving external requests and forwarding them to the right destination. Along the way it handles cross-cutting concerns like authentication and shared policies in one place, so individual services do not have to repeat them.

A mechanism for finding changing service locations by stable name

Service Discovery is the internal address book that resolves a stable service name to the live network locations of its instances at runtime. Callers send requests using just a name, without tracking concrete IPs or ports themselves.

A structure that connects systems around events instead of direct calls

Event-Driven Architecture replaces direct service-to-service calls with published facts. When something happens, the producing service writes an event to a channel, and any interested consumer reacts on its own. The producer does not need to know who listens, and consumers process at their own pace, which loosens the direct call graph between services.

A work buffer that absorbs the speed gap between producers and consumers

Message Queue is a work buffer that holds messages from producers until consumers are ready to pull and process them. It decouples both sides so that differences in speed do not force either to wait or collapse.

A messaging model that fans one event out to many subscribers

Publish/Subscribe is a messaging structure that fans one event out to many subscribers through a topic. The producer publishes without knowing who is listening, and each subscriber reacts independently according to its own responsibility.

A technique that keeps nearby copies of frequently read data

Caching places a copy of frequently read data closer to the read path so requests do not have to reach the primary store every time. The original data stays where it is; a faster intermediate layer intercepts repeated lookups before they hit the source. Because every copy has a limited shelf life, the technique comes with decisions about how long to trust a cached value and when to throw it away.

A pattern that splits read and write models for different needs

CQRS gives the write path and the read path their own separate models instead of forcing both through one shared representation. The write side keeps a shape aligned with domain rules and validation; the read side keeps a shape optimized for what screens or APIs actually need to show. It starts from the premise that if the questions are different, the answers should be shaped differently too.

A pattern that chains local transactions with compensation across services

Saga carries a multi-service business flow forward without a single global transaction holding everything together. Each service runs its own local transaction in sequence, and if a step fails, explicit compensation actions undo what earlier steps already committed. The defining trait is that the failure path is designed as deliberately as the success path.

A pattern that temporarily cuts failing remote calls to stop cascading failure

Circuit Breaker sits in the remote-call path and temporarily stops sending requests to a dependency that keeps failing. Instead of letting callers wait and hold resources open, it fails fast or redirects to a fallback, narrowing how far an outage spreads.

The property that keeps repeated requests from changing the result twice

Idempotency is the property that keeps final state stable even when the same request runs more than once. In environments where retries and duplicate delivery happen routinely, it anchors safety to the outcome rather than the number of executions.

The ability to infer internal system state from external signals

Observability is the instrumentation foundation that makes a system's internal behavior readable from the outside. Beyond knowing that an error occurred, it lets operators trace which segment slowed down and where a failure actually began.

A design approach that treats business boundaries as first-class structure

Domain-Driven Design treats business meaning as the primary shape of the system. Instead of starting from tables or endpoints, it starts from the language, concepts, and boundaries that the business itself uses. The goal is to make the code reflect the real domain rather than only the technical stack around it.

A single deployment unit with strong internal module boundaries

Modular Monolith keeps the system as one deployment unit while enforcing clear domain-oriented module boundaries inside it. It is still a monolith operationally, but it behaves more like a set of well-defined internal services in terms of ownership and contracts.

A structure that shields the core behind ports and adapters

Hexagonal Architecture places the business core in the middle and surrounds it with adapters for web, storage, messaging, or other technologies. The core depends only on ports, which are contracts for what it needs or exposes. That keeps business logic from being shaped directly by frameworks and infrastructure details.

A dedicated backend entry point for each client channel

Backend for Frontends creates a dedicated backend layer for each client channel such as web, mobile, or partner applications. Instead of asking clients to coordinate many domain services themselves, each BFF tailors orchestration and response shape to the needs of one channel.

A layer that spreads traffic across equivalent instances

Load Balancer is the traffic-distribution layer that sits in front of multiple equivalent service instances. Clients hit one stable address, while the balancer decides which healthy instance should receive each request. Its deeper value is not just sharing load, but hiding instance churn and failure from callers.

A proxy layer that governs service-to-service communication

Service Mesh moves repeated communication concerns such as retries, timeouts, mTLS, and tracing out of individual service code into a shared proxy layer. Services focus on business behavior while sidecars or node-level proxies handle the mechanics of service-to-service traffic.

A model that stores events rather than only current state

Event Sourcing records the sequence of state-changing events rather than repeatedly overwriting a current-state row. The current state is reconstructed from that event history, and alternative read models can be built from the same stream.

A pattern that couples local state change with reliable event release

Outbox Pattern stores an integration event alongside business state in the same local transaction, then releases that event asynchronously through a relay process. It makes reliable publication a two-step process: record first, deliver second.

A consistency model that allows delay in exchange for convergence

Eventual Consistency is the model where different parts of a distributed system may temporarily show different values, but are designed to converge over time. The key design question becomes not whether everything is identical instantly, but whether the system can tolerate delay while still reaching the right final state.

A pattern that isolates resource pools to contain failure spread

Bulkhead separates resource pools so one overloaded path or dependency cannot consume all shared capacity. Like ship compartments, the goal is not to prevent every local failure, but to stop that failure from flooding the whole service.