Kiến trúc phần mềmSoftware Architecture

Part of the Backend Roadmap knowledge base.

Overview

Software architecture is the set of high-level structural decisions about a system: how it is decomposed into parts, how those parts communicate, where data lives, and which qualities (performance, scalability, resilience, maintainability, security, cost) you optimize for. These are the decisions that are expensive to change later — Grady Booch’s often-quoted definition is that “architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.”

For a backend engineer, architecture is not an abstract diagram exercise. It directly determines:

• How fast a team can ship features without stepping on each other.
• How the system behaves under load and under failure.
• How much it costs to operate (servers, network, on-call burden).
• How hard it is to reason about, test, and evolve.

There is no single “best” architecture — every choice is a trade-off. A three-person startup and a 300-engineer company solving the “same” problem should almost never pick the same architecture. The job is to understand the forces at play (team size, domain complexity, scale requirements, deadlines) and pick the simplest thing that satisfies them, while keeping the door open to evolve.

This note covers the foundational principles (coupling, cohesion, separation of concerns, layering), the major architectural patterns and styles (layered, hexagonal, clean, event-driven, CQRS, event sourcing), the big deployment-topology debate (monolith vs microservices vs SOA vs serverless, plus the modular monolith middle ground), the specific concerns microservices introduce (boundaries, communication, data ownership, sagas, gateways, discovery, service mesh), the Twelve-Factor App methodology, evolutionary architecture and the strangler fig pattern, and the classic design principles (SOLID, DRY, KISS, YAGNI).

Related notes: APIs · Message Brokers and Async Processing · Scalability and Reliability.

Fundamentals

Before choosing a pattern or a topology, internalize a handful of principles. Every good architecture is an application of these; every bad one violates them.

Coupling and cohesion

These are the two most important words in software design. Almost every architectural rule reduces to “lower coupling, higher cohesion.”

• Coupling — the degree to which one module depends on another. When two modules are tightly coupled, a change in one forces a change in the other. High coupling makes systems brittle: small changes ripple widely, and you cannot understand or deploy a module in isolation.
• Cohesion — the degree to which the elements inside a module belong together. High cohesion means a module does one well-defined thing; everything in it serves that single purpose. Low cohesion is a “grab bag” module (Utils, Helpers, Manager) that does unrelated things.

The goal: low coupling between modules, high cohesion within each module. Robert C. Martin frames this as “gather together the things that change for the same reason; separate the things that change for different reasons” — the essence of the Single Responsibility Principle.

Types of coupling, from loosest (good) to tightest (bad): message coupling → data coupling (passing simple parameters) → stamp coupling (passing whole structures) → control coupling → shared/global coupling → content coupling (one module reaching into another’s internals). Prefer the loosest form that gets the job done.

Separation of concerns

Separation of concerns (SoC) is the principle of dividing a system so each part addresses a distinct concern (persistence, business rules, presentation, transport). Each concern can then be understood, changed, and tested independently. Layering (below) is one common realization; hexagonal architecture is another.

The practical payoff: you can swap your database, change your API framework, or replace your UI without rewriting business logic — if those concerns were properly separated in the first place.

Layering

A layer is a horizontal slice of responsibility. A dependency rule constrains layers: higher layers may depend on lower layers, never the reverse. A classic backend stack:

Layering gives you clear seams for testing (mock the layer below), a shared mental model for the team, and controlled dependencies. Its risk is the anemic domain model and the “sinkhole anti-pattern” — requests that pass straight through every layer doing nothing but forwarding, adding ceremony without value. Layers should earn their keep.

Architecture vs design vs implementation

A useful mental scale:

• Architecture — system-wide, hard to reverse (monolith vs microservices, sync vs async, SQL vs NoSQL).
• Design — module-level, moderately reversible (which pattern, class structure, interfaces).
• Implementation — line-level, cheap to change (variable names, a specific loop).

Spend your careful, up-front thinking budget in proportion to reversibility. Architecture decisions deserve an ADR (Architecture Decision Record): a short document capturing the context, the decision, and the consequences, committed alongside the code.

Key Concepts

Architectural patterns and styles

These describe how you structure code within a deployable unit. They are largely independent of, and combinable with, the deployment topology (monolith/microservices) discussed later.

Layered / N-tier

The default and most widely used pattern (described above). Code is organized into horizontal layers (presentation, business, persistence). “N-tier” adds physical deployment tiers (web tier, app tier, DB tier). Simple, familiar, great for CRUD-heavy apps. Weakness: business logic tends to leak into controllers and the DB schema tends to drive the design (“database-centric”).

Hexagonal (Ports and Adapters)

Coined by Alistair Cockburn. The application core (domain + use cases) sits in the center and knows nothing about the outside world. It defines ports (interfaces) for what it needs (OrderRepository, PaymentGateway) and what it offers (use-case interfaces). Adapters on the outside implement those ports for specific technologies (a Postgres adapter, a Stripe adapter, an HTTP controller, a Kafka consumer).

The key win: the domain depends on abstractions, not on frameworks or databases. You can test the core with in-memory adapters, and swap infrastructure by writing a new adapter. This is a concrete realization of the Dependency Inversion Principle.

Clean Architecture

Robert C. Martin’s synthesis of hexagonal, onion, and other “dependency-rule” architectures. Concentric circles: Entities (enterprise rules) → Use Cases (application rules) → Interface Adapters (controllers, presenters, gateways) → Frameworks & Drivers (web, DB, UI). The Dependency Rule: source-code dependencies point only inward. Inner circles never know about outer circles; crossing the boundary uses interfaces and DTOs. Practically very similar to hexagonal, with more prescriptive naming.

Event-Driven Architecture (EDA)

Components communicate by producing and consuming events (“something happened”) rather than calling each other directly. A producer emits OrderPlaced; any number of consumers react (charge payment, reserve stock, send email) without the producer knowing they exist. Two topologies:

• Broker / pub-sub — events flow through a broker (Kafka, RabbitMQ, NATS); consumers subscribe. Highly decoupled, scalable.
• Mediator / orchestration — a central orchestrator directs a multi-step workflow.

Strengths: extreme decoupling, natural scalability, responsiveness. Costs: eventual consistency, harder debugging (no single call stack), the need for idempotency and careful error handling. See Message Brokers and Async Processing.

CQRS (Command Query Responsibility Segregation)

Separate the model that writes data (commands) from the model that reads it (queries). Instead of one model serving both, you have a write model optimized for validation and consistency, and one or more read models (often denormalized, in a different store) optimized for query performance. The two are kept in sync, usually asynchronously via events.

Use it when read and write workloads are very different, or reads vastly outnumber writes. Avoid it for simple CRUD — it adds real complexity (two models, sync lag, eventual consistency).

Event Sourcing

Instead of storing the current state, store the full sequence of events that led to it. State is derived by replaying events. The event log is the source of truth and is append-only.

Benefits: a complete audit trail for free, the ability to reconstruct state at any past point (“time travel”), and natural fit with CQRS and EDA. Costs: querying current state requires projections, schema/versioning of events is hard, and it is a big conceptual shift. Often paired with CQRS. Reserve it for domains where history itself is valuable (finance, ledgers, audit-heavy systems).

Deployment topologies: Monolith vs Microservices vs SOA vs Serverless

This is the debate most people mean by “architecture.” It is about how the system is packaged, deployed, and run — orthogonal to the internal patterns above (you can build a well-layered monolith or a big-ball-of-mud microservice).

Monolith

A single deployable unit containing all functionality. One codebase, one build, one deploy, usually one database.

• Pros: simplest to build, test, deploy, and debug; no network between components (fast, no partial failure); transactions are trivial (one DB, ACID); one place to look. Best starting point for almost every project.
• Cons: as it grows, coupling creeps in; the whole thing deploys together (one team’s change waits on another’s); scaling means scaling everything; a single memory leak can take down all features; hard to adopt new tech incrementally.

A monolith is not inherently bad. A poorly structured monolith (“big ball of mud”) is. Which leads to:

Modular Monolith (the middle ground)

A single deployable unit that is internally divided into well-bounded, loosely coupled modules with explicit interfaces — often each module owning its own schema/tables and communicating through in-process APIs or events, never reaching into each other’s internals. You get monolith simplicity (one deploy, one process, in-process calls, easy transactions) with much of the modularity that makes microservices attractive.

This is the recommended default for most teams today. It keeps future options open: if a module genuinely needs independent scaling or deployment, its clean boundary makes extracting it into a service much easier. Start here; extract services only when a real, measured need appears.

Microservices

The system is decomposed into many small, independently deployable services, each owning a bounded slice of the business and its own data. Services communicate over the network (HTTP/gRPC or async messaging).

• Pros: independent deployment (teams ship without coordinating); independent scaling (scale only the hot service); technology heterogeneity (right tool per service); fault isolation (one service failing needn’t take down others, with proper design); aligns with autonomous teams.
• Cons: you trade code complexity for distributed-system complexity — network latency and partial failure, eventual consistency, distributed transactions, distributed debugging/tracing, operational overhead (deployment, monitoring, service discovery per service), and data duplication. As Martin Fowler notes, microservices come with a significant “microservices premium” that only pays off past a certain scale and team size.

Do not start with microservices. The strong recommendation (“MonolithFirst”) is to begin with a (modular) monolith and extract services as bounded contexts prove stable and independent scaling/deployment needs emerge.

SOA (Service-Oriented Architecture)

The enterprise predecessor of microservices (2000s). Also service-based, but typically coarser-grained services, sharing infrastructure, and — critically — orchestrated through a heavyweight ESB (Enterprise Service Bus) that handles routing, transformation, and orchestration centrally, often over SOAP/WS-* protocols. The ESB tended to become a bottleneck and a source of coupling. Microservices reacted against this: “smart endpoints, dumb pipes” — put logic in services, keep the transport (a simple broker or plain HTTP) dumb. Services also own their own data, whereas SOA often shared a database.

Serverless (FaaS)

Functions (or managed services) run on-demand; the provider handles all server management, and you pay per execution. Each function is tiny, stateless, and event-triggered (HTTP request, queue message, file upload, cron).

• Pros: no server management, automatic scaling (including to zero), pay-per-use (cheap at low/spiky traffic), fast to build small event-driven pieces.
• Cons: cold starts, execution time/memory limits, vendor lock-in, harder local testing, statelessness forces external state, and cost can exceed dedicated servers at high steady traffic. Great for glue, event processing, and spiky workloads; less ideal as the backbone of a large, high-throughput core system.

Comparison table

Rule of thumb: Start with a modular monolith. Move to microservices when (and only when) you feel real, measured pain — deployment coordination, scaling hotspots, team autonomy — that a monolith cannot solve. Conway’s Law (below) means the split should follow team and domain boundaries, not fashion.

Microservices-specific concerns

If you do go distributed, these are the problems you must solve. Ignoring any of them is how microservices become a “distributed monolith” — all the cost, none of the benefit.

Service boundaries: DDD bounded contexts

The hardest and most important decision. Getting boundaries wrong is the #1 cause of failed microservices. The best tool is Domain-Driven Design’s bounded context: a boundary within which a domain model and its ubiquitous language are consistent. Customer might mean something different in Sales than in Support — those are two bounded contexts, and each maps well to a service. Boundaries should be high-cohesion, low-coupling slices of the business, not technical layers. A good boundary can be developed, deployed, and reasoned about mostly in isolation.

Inter-service communication: sync vs async

Prefer async messaging to reduce temporal coupling wherever an immediate answer isn’t required. For synchronous calls, always apply resilience patterns (timeouts, retries with backoff, circuit breakers, bulkheads) — see Scalability and Reliability. See also Message Brokers and Async Processing.

Data ownership: database per service

The defining rule of microservices data: each service owns its data, and no other service touches its database directly. Other services get data only via the owning service’s API or via events. A shared database re-couples services (a schema change breaks everyone) and destroys independent deployability. The cost is data duplication and eventual consistency across services — which the next two concerns address.

Distributed transactions: the Saga pattern

You cannot use a single ACID transaction across multiple services’ databases. Instead, a business transaction spanning services becomes a saga: a sequence of local transactions, each publishing an event or command that triggers the next. If a step fails, the saga runs compensating transactions to undo prior steps.

• Choreography — no central coordinator; each service reacts to events and emits the next. Simple and decoupled, but the overall flow is implicit and hard to follow at scale.
• Orchestration — a central saga orchestrator explicitly drives each step and handles compensation. More visible and controllable; the orchestrator is a new component to build and operate.

Sagas give you eventual consistency and atomicity-via-compensation, not isolation — design for intermediate states being observable.

API Gateway

A single entry point in front of the services. It handles cross-cutting concerns so each service doesn’t have to: routing/aggregation, authentication and authorization, rate limiting, TLS termination, request/response transformation, and caching. It shields clients from the internal service topology (a client calls one endpoint instead of ten). Variant: Backend for Frontend (BFF) — a gateway per client type (web, mobile) tailored to that client’s needs. Watch out for the gateway becoming a bottleneck or a new monolith of business logic — keep it thin.

Service discovery

With many services on dynamic hosts/ports (containers scale up and down, IPs change), services can’t hardcode each other’s addresses. Service discovery solves this:

• Client-side — the client queries a registry (Consul, Eureka, etcd) and picks an instance.
• Server-side — the client hits a stable load balancer / DNS name that routes to a live instance (the Kubernetes Service model).

Service mesh

As inter-service concerns (retries, mTLS, timeouts, traffic shaping, observability) proliferate, implementing them in every service in every language becomes untenable. A service mesh (Istio, Linkerd) moves them into a sidecar proxy deployed next to each service. The data plane (sidecars, e.g. Envoy) handles the actual traffic — mTLS, load balancing, retries, circuit breaking; the control plane configures the sidecars centrally. The application code stays oblivious. The trade-off is added operational and latency overhead, so adopt it only when the number of services justifies it.

Integration patterns

Three broad ways systems and services integrate, roughly from most-coupled to least:

• Shared data — services read/write a common database or files. Simple but the tightest coupling; the schema becomes a shared contract that resists change. Acceptable within a modular monolith module, discouraged across microservices.
• API / RPC (request-response) — one service calls another’s API (REST, gRPC, GraphQL). Clear contracts and immediate answers, at the cost of temporal coupling and runtime dependency. See APIs.
• Messaging (events/commands) — services exchange messages through a broker. The loosest coupling and the backbone of event-driven systems; introduces eventual consistency and requires idempotent consumers. See Message Brokers and Async Processing.

A healthy distributed system uses all three deliberately: messaging for decoupled workflows and notifications, APIs for queries needing an immediate answer, shared data confined within a single service or module.

The Twelve-Factor App

A methodology (from Heroku) for building portable, scalable, cloud-native applications. Even outside its original PaaS context, it is a superb checklist for backend service design:

1. Codebase — one codebase tracked in version control, many deploys.
2. Dependencies — explicitly declare and isolate dependencies; never rely on system-wide packages.
3. Config — store config (anything that varies per environment) in the environment, not in code.
4. Backing services — treat backing services (DB, cache, queue) as attached, swappable resources referenced by URL/config.
5. Build, release, run — strictly separate the build, release, and run stages.
6. Processes — run the app as one or more stateless, share-nothing processes; persist state in backing services.
7. Port binding — export services via port binding; the app is self-contained and binds to a port.
8. Concurrency — scale out horizontally via the process model (more processes), not just bigger machines.
9. Disposability — maximize robustness with fast startup and graceful shutdown; processes are disposable.
10. Dev/prod parity — keep development, staging, and production as similar as possible.
11. Logs — treat logs as event streams written to stdout; let the environment route and store them.
12. Admin processes — run admin/management tasks (migrations, one-off scripts) as one-off processes in the same environment.

Evolutionary architecture and refactoring

Architecture is not decided once. Evolutionary architecture (Ford, Parsons, Kua) designs for change: support guided, incremental change across multiple dimensions over time. Key ideas:

• Fitness functions — automated checks that guard architectural characteristics (e.g., “no cyclic dependencies between modules,” “p99 latency < 200 ms,” “the API layer never imports the persistence layer”). They turn architecture principles into tests that fail the build when violated.
• Incremental change — small, reversible steps over big-bang rewrites.
• Continuous refactoring — pay down architectural debt continuously rather than in a rewrite.

Strangler Fig: monolith → microservices

Named by Martin Fowler after the strangler fig vine, this is the safe way to migrate a monolith incrementally rather than a risky “big-bang rewrite.” You place a facade/proxy in front of the monolith and, piece by piece, extract functionality into new services. The facade routes each request to either the new service (for migrated features) or the old monolith (for the rest). Over time the new system “strangles” the old one until it can be retired.

Advantages: no risky rewrite, continuous delivery of value, ability to pause or roll back, and gradual learning. It requires discipline to actually finish (avoid the “permanent hybrid” where migration stalls forever).

Core design principles

The reusable principles underneath all of the above:

• SOLID — five OO principles:
  • Single Responsibility — a class/module has one reason to change.
  • Open/Closed — open for extension, closed for modification.
  • Liskov Substitution — subtypes must be usable wherever their base type is expected.
  • Interface Segregation — many small, focused interfaces beat one fat interface.
  • Dependency Inversion — depend on abstractions, not concretions (the basis of hexagonal/clean architecture).
• DRY (Don’t Repeat Yourself) — every piece of knowledge has a single, authoritative representation. Beware over-applying it to coincidental duplication (see AHA: “avoid hasty abstractions”).
• KISS (Keep It Simple, Stupid) — prefer the simplest solution that works; complexity must earn its place.
• YAGNI (You Aren’t Gonna Need It) — don’t build for speculative future requirements; implement things when you actually need them.

Trade-offs, cost, and Conway’s Law

Architecture is the art of trade-offs. Three lenses to apply to any decision:

• Complexity budget — distribution, async, and extra layers all add cognitive and operational complexity. Every added element must buy more than it costs. The default should be the simplest thing that works.
• Operational cost — microservices multiply what you must run and observe: more deployment pipelines, more monitoring, more failure modes, more on-call. Factor total cost of ownership, not just development speed.
• Team topology and Conway’s Law — “organizations design systems that mirror their own communication structure” (Melvin Conway, 1967). Your service boundaries will tend to match your team boundaries whether you plan it or not. The Inverse Conway Maneuver turns this into a tool: deliberately shape teams around the architecture you want. Team Topologies formalizes this with stream-aligned teams owning bounded contexts and platform teams reducing their cognitive load.

Best Practices

• Start simple; default to a modular monolith. Reach for microservices only when real, measured pain (deployment coordination, scaling hotspots, team autonomy) justifies the distributed-systems premium.
• Design around business capabilities / bounded contexts, not technical layers. Boundaries are the decision that matters most — get cohesion high and coupling low.
• Depend on abstractions, not frameworks. Keep business logic independent of the DB, the web framework, and external services (hexagonal/clean). It should be testable without any of them running.
• Enforce database-per-service in microservices; never let services share a database. Integrate through APIs and events instead.
• Prefer asynchronous messaging to cut temporal coupling; use synchronous calls only when you need an immediate answer, and always wrap them in timeouts, retries, and circuit breakers.
• Embrace eventual consistency where strong consistency isn’t required; use sagas for cross-service business transactions and make consumers idempotent.
• Apply the Twelve-Factor principles — stateless processes, config in the environment, logs to stdout, dev/prod parity — to every service.
• Make architecture testable with fitness functions (dependency rules, latency budgets, module boundaries) so violations fail the build.
• Migrate incrementally (strangler fig), never with a big-bang rewrite.
• Record decisions in ADRs. Capture context, decision, and consequences so future maintainers understand why.
• Respect Conway’s Law. Align teams and services deliberately; don’t fight your org chart.
• Avoid premature abstraction (YAGNI) and premature distribution. The most expensive architectures are usually the over-engineered ones.

References

• The Twelve-Factor App
• Martin Fowler — Microservices
• Martin Fowler — MonolithFirst
• Martin Fowler — Strangler Fig Application
• microservices.io — Patterns (Sam Newman / Chris Richardson)
• Robert C. Martin — The Clean Architecture
• Alistair Cockburn — Hexagonal Architecture
• Domain-Driven Design Reference (Eric Evans)