Architecture Builder

Build a software architecture step by step by choosing components, layers, and connections based on the system's requirements.

Objective

In this lab you will design a software architecture from scratch. Starting from a set of business and technical requirements, you will choose the components, layers, and connections that best solve the problem at hand.

The goal is not to arrive at “the right answer” — it is to practice the process of making architectural decisions with sound judgment.

Scenario: E-commerce platform

Imagine you are asked to design the architecture for an e-commerce platform with the following requirements:

Concurrent users: up to 10,000 simultaneously
Catalog: 50,000 products with search and filters
Payments: integration with at least 2 external providers
Notifications: real-time email and push
Availability: 99.9% uptime

Step 1 — Choose the architectural style

Before thinking about technologies, define the overall style:

Style	Advantages	Disadvantages	When to choose it?
Modular monolith	Simple to deploy, easy to debug	Limited scaling, internal coupling	Small teams, MVP
Microservices	Independent scaling, autonomous deployment	Operational complexity, network latency	Large teams, clear domains
Hybrid	Balance between simplicity and scalability	Requires discipline around boundaries	Gradual growth

Exercise

Given the scenario, which style would you choose? Consider:

The size of the available team
The need to scale components independently (catalog vs payments)
The operational complexity you can take on

Step 2 — Define the system layers

Once you have chosen the style, define the main layers:

Presentation layer

SPA, SSR, or a static site?
Do you need a BFF (Backend for Frontend)?
How do you handle authentication on the frontend?

Application layer

How many services do you need?
How do they communicate with each other (sync vs async)?
Where does the critical business logic live?

Data layer

One database or several?
SQL, NoSQL, or both?
Do you need a cache? Where?

Infrastructure layer

Cloud, on-premise, or hybrid?
Containers, serverless, or VMs?
How do you handle secrets and configuration?

Step 3 — Connect the components

Define how the pieces communicate:

[Frontend SPA]
    │
    ▼
[API Gateway / BFF]
    │
    ├──► [Catalog Service] ──► [PostgreSQL + Redis Cache]
    │
    ├──► [Orders Service] ──► [PostgreSQL]
    │         │
    │         ▼
    │    [Event Bus]
    │         │
    │         ├──► [Payments Service] ──► [External Provider]
    │         └──► [Notifications Service] ──► [Email/Push]
    │
    └──► [Auth Service] ──► [Redis Sessions]

Key questions

What happens if the payments service does not respond?
How do you guarantee that an order is not processed twice?
Where do you implement circuit breakers?
How do you handle eventual consistency between services?

Step 4 — Evaluate trade-offs

Every architectural decision has trade-offs. Document yours:

Decision	Accepted trade-off	Mitigation
Microservices for catalog and payments	Greater operational complexity	Kubernetes + automated CI/CD
Event bus for async communication	Eventual consistency	Idempotency + retry with backoff
Redis as a catalog cache	Potentially stale data	5-minute TTL + event-based invalidation
PostgreSQL for transactional data	Limited vertical scaling	Read replicas + partitioning

Step 5 — Validate against requirements

Check that your architecture meets each original requirement:

Does it support 10,000 concurrent users? Where is the bottleneck?
Is catalog search fast? Do you use indexes or a search engine?
Are payments resilient to provider failures?
Do notifications arrive in real time?
Can you reach 99.9% uptime with this architecture?

Reflection

When you finish, ask yourself:

Which decision was the hardest? Why?
What would you change if the team were 3 people instead of 15?
What would you change if the availability requirement were 99.99%?
Is there any component you could remove without losing critical functionality?

The perfect architecture does not exist — but a well-reasoned and well-documented architecture is invaluable.