Software Architecture

What is Software Architecture?

Software architecture is the set of fundamental decisions about a system's structure — how it is divided into components, how those components interact, and what constraints govern those interactions.

The architect (or SA) makes these decisions early in the project. They are expensive to change later because the whole system is built on top of them.

Why Does It Matter for Analysts?

Monolithic Architecture

All functionality is deployed as a single unit.

[User] → [Web Server]
              ↓
       [Single Application]
       ├── Auth module
       ├── Orders module
       ├── Inventory module
       └── Reporting module
              ↓
         [Database]

Pros: Simple to develop, test, and deploy initially. One codebase, one deployment.

Cons: As the system grows — harder to scale, deploy, and understand. One bug can crash the whole system.

When to use: Startups, MVPs, small teams, systems with simple domain.

Service-Oriented Architecture (SOA)

Business functionality is split into reusable services communicating through an Enterprise Service Bus (ESB).

Pros: Reusability, enterprise integration across departments.

Cons: ESB becomes a single point of failure and bottleneck. Complex governance.

When to use: Large enterprises integrating legacy systems (banking, insurance, telco).

Microservices Architecture

The system is decomposed into small, independently deployable services, each owning its data.

[API Gateway]
     ├── [User Service]    → [users_db]
     ├── [Order Service]   → [orders_db]
     ├── [Payment Service] → [payments_db]
     └── [Notify Service]  → [Redis / Queue]

Pros: Independent deployment, technology diversity, fault isolation, scale each service separately.

Cons: Distributed system complexity, network latency, data consistency challenges, operational overhead.

When to use: Large teams, high-load systems, when independent scaling matters.

Event-Driven Architecture (EDA)

Components communicate by publishing and consuming events asynchronously through a message broker (Kafka, RabbitMQ).

[Order Service] → publishes OrderPlaced → [Kafka]
                                              ↓
                          ┌───────────────────┤
                   [Inventory]          [Shipping]    [Email]

Pros: Loose coupling, high throughput, natural audit trail.

Cons: Eventual consistency, harder to trace flows, ordering guarantees complex.

When to use: High-volume data pipelines, real-time systems, audit-heavy domains.

Serverless Architecture

Business logic runs in stateless functions (AWS Lambda, Azure Functions) triggered by events. No servers to manage.

Pros: Zero infrastructure management, pay-per-use pricing, automatic scaling.

Cons: Cold starts, execution time limits, vendor lock-in, hard to test locally.

When to use: Infrequent workloads, glue functions, event processing pipelines.

Comparison Table

Layered (N-Tier) Architecture

The most common pattern. The system is divided into horizontal layers, each with a specific responsibility. Each layer only communicates with the layer directly below it.

┌──────────────────────────┐
│   Presentation Layer     │  → UI, REST controllers, GraphQL resolvers
├──────────────────────────┤
│   Business Logic Layer   │  → Use cases, domain rules, orchestration
├──────────────────────────┤
│   Data Access Layer      │  → Repositories, ORM, SQL queries
├──────────────────────────┤
│   Database Layer         │  → PostgreSQL, MongoDB, Redis
└──────────────────────────┘

Pros: Easy to understand, widely adopted, clear separation of concerns.

Cons: "Lasagna code" — changes ripple through all layers. Business logic often leaks into other layers.

Hexagonal Architecture (Ports & Adapters)

Also called "Clean Architecture." The business domain is at the center and knows nothing about databases, UI, or external services. External concerns attach through "ports" (interfaces) and "adapters" (implementations).

             [REST API Adapter]
                    ↓
              [HTTP Port]
                    ↓
         [Application Core]
         (domain + use cases)
                    ↓
           [Database Port]
                    ↓
       [PostgreSQL Adapter]   [MongoDB Adapter]

Key rule: Dependencies point inward. The domain never imports from infrastructure.

Pros: Highly testable (swap adapters), infrastructure is replaceable, domain is isolated.

Cons: More abstractions, steeper learning curve, initial setup overhead.

When to use: Complex domains, long-lived systems, when testability matters.

CQRS — Command Query Responsibility Segregation

Separate the read model (queries) from the write model (commands).

[Client]
  ├── Command → [Write Model] → [Write DB]
  │              (validates,         ↓
  │               executes)    [Event Published]
  │                                  ↓
  └── Query  → [Read Model]  ← [Read DB (denormalized)]
               (no validation,
                fast reads)

Why CQRS?

• Read and write requirements are different: reads are frequent and need to be fast; writes are rare and need to be correct.
• The write model can be normalized for integrity; the read model can be denormalized for performance.

Pros: Optimized read and write paths, can scale them independently.

Cons: Eventual consistency between read and write models, more complex codebase.

Event Sourcing

Instead of storing the current state of a record, store a sequence of events that led to that state.

Instead of:  accounts row: { id: 42, balance: 1500 }

Store: AccountOpened { account_id: 42, initial: 0 } MoneyDeposited { account_id: 42, amount: 2000 } MoneyWithdrawn { account_id: 42, amount: 500 } → Current balance: 1500 (replayed from events) ```

Pros: Full audit trail, can reconstruct state at any point in time, natural fit with CQRS.

Cons: Querying current state requires event replay (mitigated with snapshots), schema evolution is complex.

Best fit: Financial systems, compliance-heavy domains, audit logs.

Choosing the Right Pattern

What are Non-Functional Requirements (NFRs)?

NFRs describe HOW a system performs its functions, not WHAT it does. They are also called quality attributes or system-ilities.

Missed or vague NFRs are one of the top causes of project failure and production incidents.

Key Quality Attributes

### Performance

How fast the system responds under normal and peak conditions.

BA/SA Task: Define concrete numbers, not "the system should be fast."

Bad: "The system should respond quickly." Good: "95% of API requests must complete in < 200ms under load of 500 concurrent users."

### Scalability

The system's ability to handle increased load by adding resources.

• Vertical scaling: add more CPU/RAM to existing servers
• Horizontal scaling: add more server instances behind a load balancer

Key question: "What happens when we get 10× more users?"

### Availability & Reliability

### Security

Protection from unauthorized access, data breaches, and attacks.

### Maintainability

How easy it is to change, fix, or extend the system.

### Portability

Ability to move the system to different environments (cloud providers, OS, databases).

Quality Attribute Scenario Format

A structured way to make NFRs testable:

This format ensures NFRs are verifiable and unambiguous.