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.