Software architecture
Software architecture is the set of structural decisions about a system: which components exist, what each one is responsible for, how they communicate and where data lives. It covers choices that are costly to reverse, such as a monolith versus separate services, synchronous calls versus message queues, or building a capability versus buying it. Diagrams such as those of the C4 model describe it at several levels of zoom.
Why it matters for a PM
Architecture determines what the product can change quickly, what it costs to run and how it fails. PMs do not design it, but they bring the constraints that should shape it (expected load, response times, data sensitivity, deadlines) and need to understand the trade-offs well enough to ask good questions in an architecture review.
Example
A marketplace sends order confirmation emails synchronously, so checkout slows down whenever the email provider is slow. Moving the emails to a message queue makes checkout fast again, at the cost of a confirmation that may arrive a few seconds after the order page.
Key points
- Read a diagram from the outside in: users and external systems, then containers, then components.
- A modular monolith is often a better starting point than microservices for a small team.
- Asynchronous processing improves resilience and responsiveness but brings eventual consistency.
- Major decisions and their alternatives go into an architecture decision record (ADR).
- Each third-party dependency adds its own availability and lock-in risks to yours.
Common mistakes
- Choosing an architecture for its popularity rather than for the product's constraints.
- Leaving non-functional requirements unstated, then blaming the architecture.
- Treating architecture reviews as engineering-only meetings.
Go further with Module
The courses and lessons that cover this concept: