Introduction
Software architecture is the set of high-level decisions about how a system is structured: what its major components are, how they communicate, and how responsibilities are divided among them. While a single class diagram or design pattern addresses a local problem, architecture addresses the shape of the whole system — the boundaries between the UI, business logic, data storage, and external services. Getting the architecture right early on makes a system easier to build, test, deploy, and change later; getting it wrong is expensive to undo.
Cricket analogy: Software architecture is like deciding a franchise's overall team structure, batting order, bowling attack, and fielding roles, not the technique of any one player; getting the balance of pace versus spin right before the season starts is far cheaper than restructuring the whole squad mid-tournament.
Explanation
Architecture is distinct from design patterns. Design patterns (like Singleton, Observer, or Strategy) solve recurring problems inside a component, at the level of classes and objects. Architecture operates one level up: it decides what the components even are, and how data and control flow between them. Three common architectural styles illustrate this: Layered architecture organizes a system into horizontal layers — for example presentation, business logic, and data access — where each layer only talks to the layer directly below it, which keeps concerns separated and makes each layer independently testable. Client-server architecture splits a system into a server that owns shared resources and logic, and one or more clients that request services from it over a network; the web itself is a giant client-server system, with browsers as clients and web servers as servers. Event-driven architecture organizes components around the production and consumption of events: a component emits an event when something happens (an order was placed, a file was uploaded) and other components subscribe and react asynchronously, without the emitter needing to know who is listening.
Cricket analogy: A specific fielding drill (like slip-catching practice) is a design pattern solving a local problem; team architecture is one level up, deciding the whole structure. Layered is like a strict batting order where each batsman only hands off to the next. Client-server is like a coaching academy where one head coach serves instructions to many trainee batsmen. Event-driven is like a scoreboard operator reacting to whatever happens on the field, a boundary, a wicket, without knowing in advance who's watching the screen.
Example
+------------------+
| Presentation | (Web UI / mobile app)
+------------------+
|
v
+------------------+
| Business Logic | (Services, rules, workflows)
+------------------+
|
v
+------------------+
| Data Access | (Repositories, ORM)
+------------------+
|
v
+------------------+
| Database |
+------------------+
A classic 3-layer architecture: each layer depends only
on the layer beneath it, never the reverse.Analysis
No single architectural style is universally correct — the choice depends on the system's requirements. A small internal admin tool may be perfectly served by a simple layered architecture, while a system that needs to react to thousands of real-time sensor readings is a natural fit for event-driven architecture. Client-server thinking underlies almost every networked application, from mobile apps talking to a REST API to a browser talking to a web server. A common beginner mistake is to treat architecture as a one-time decision baked in stone; in practice, architecture evolves as a system grows, and the goal is to choose a style — or combination of styles — that matches today's requirements without making tomorrow's changes unreasonably hard.
Cricket analogy: A small local club team might be well served by a simple layered structure of batting, bowling, and fielding coaches reporting up a chain, while a national team facing constant last-minute injury and form changes benefits from an event-driven approach where selectors react to whatever happens; club-server thinking, one franchise's academy serving many age-group teams, underlies most cricket development systems, and no team should treat its structure as fixed forever, since a rebuilding squad's needs differ from a championship-defending one.
Key Takeaways
- Architecture defines a system's major components and how they interact — a level above individual design patterns.
- Layered architecture separates concerns into horizontal layers (e.g. presentation, business logic, data access).
- Client-server architecture splits responsibility between a service provider (server) and requesters (clients) over a network.
- Event-driven architecture decouples components by having them communicate through asynchronous events rather than direct calls.
Practice what you learned
1. What is the primary difference between a design pattern and a software architecture?
2. In a strict layered architecture, how should the presentation layer access the database?
3. Which architectural style best fits a system where components react asynchronously to things that happen elsewhere, without knowing who else is listening?
4. In client-server architecture, what is the server primarily responsible for?
Was this page helpful?
You May Also Like
Monolith vs Microservices
Compares monolithic and microservices architectures across deployment, scaling, communication, complexity, and failure isolation.
MVC Architecture Pattern
An architectural pattern that separates an application into Model (data), View (presentation), and Controller (input mediation) layers.
Design Patterns Overview
An introduction to the Gang of Four design patterns and their three categories: Creational, Structural, and Behavioral.
Scalability and Load Balancing Concepts
Explains vertical vs horizontal scaling and how load balancers distribute traffic across servers, including round robin and least connections.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics