Architecture Quiz
Test your knowledge with multiple-choice questions on software architecture patterns, decisions, and concepts.
Goal
This quiz covers the fundamental software architecture concepts addressed in the previous sections. Use it to assess your understanding and spot areas where you need to dig deeper.
Each question has a detailed explanation — don’t just settle for the correct answer, read the why behind it.
Section 1: Fundamentals
Question 1
What is the main difference between a monolith and microservices?
- A) Microservices use more technologies
- B) Microservices are deployed independently
- C) Monoliths can’t scale
- D) Microservices are always faster
Show answer
Answer: B
The fundamental difference is independent deployment. Each microservice can be deployed, scaled, and updated without affecting the others. A monolith is deployed as a single unit.
Monoliths can indeed scale (vertically or with multiple instances). Microservices aren’t inherently faster — in fact, network communication adds latency.
Question 2
Which architectural principle suggests that high-level modules should not depend on low-level modules?
- A) Single Responsibility Principle
- B) Open/Closed Principle
- C) Dependency Inversion Principle
- D) Interface Segregation Principle
Show answer
Answer: C
The Dependency Inversion Principle (DIP) states that:
- High-level modules should not depend on low-level modules. Both should depend on abstractions.
- Abstractions should not depend on details. Details should depend on abstractions.
In practice, this means using interfaces or contracts between layers, not direct dependencies on concrete implementations.
Question 3
When is it appropriate to choose a monolith over microservices?
- A) Never — microservices are always superior
- B) When the team is small and the domain isn’t well defined
- C) Only for throwaway prototypes
- D) When you don’t have a budget for cloud
Show answer
Answer: B
A monolith (especially a modular monolith) is an excellent choice when:
- The team is small (< 8 people)
- The domain isn’t well defined (service boundaries will change)
- Development speed matters more than independent scalability
- You don’t have the infrastructure to operate distributed systems
Microservices add significant operational complexity. If you don’t need it, don’t add it.
Section 2: Patterns
Question 4
Which pattern would you use to prevent a slow external service from taking down your system?
- A) Saga Pattern
- B) Circuit Breaker
- C) Outbox Pattern
- D) CQRS
Show answer
Answer: B
The Circuit Breaker detects when an external service is failing or responding slowly, and “opens the circuit” to stop sending it requests. This prevents threads from blocking while waiting for responses that never arrive, protecting your system from a cascade of failures.
Circuit breaker states:
- Closed: everything works normally, requests pass through
- Open: the service is failing, requests are rejected immediately
- Half-open: a test request is allowed through to see whether the service has recovered
Question 5
What is the main purpose of the Outbox pattern?
- A) Sending emails asynchronously
- B) Guaranteeing consistency between the database and the message broker
- C) Storing failed messages to retry them
- D) Separating reads from writes
Show answer
Answer: B
The Outbox Pattern solves the dual-write problem: when you need to update the database AND publish an event, and both operations must be atomic.
Instead of publishing directly to the broker, you write the event into an “outbox” table within the same database transaction. A separate process reads the outbox table and publishes the events to the broker. If the publish fails, it’s retried. If the transaction fails, the event was never written to the outbox.
Question 6
Which pattern lets a service handle read and write requests differently?
- A) Saga
- B) Event Sourcing
- C) CQRS
- D) API Gateway
Show answer
Answer: C
CQRS (Command Query Responsibility Segregation) separates the read model from the write model. This allows you to:
- Optimize reads with denormalized models
- Scale reads and writes independently
- Use different databases for each model
CQRS doesn’t require Event Sourcing, though the two are frequently used together.
Section 3: Resilience and operations
Question 7
Which retry strategy is most appropriate for calls to external services?
- A) Immediate retry with no limit
- B) Retry with exponential backoff and jitter
- C) Retry every 1 second, up to 100 times
- D) Don’t retry — if it fails, it fails
Show answer
Answer: B
Exponential backoff with jitter is the recommended strategy because:
- Exponential backoff: each retry waits longer (1s, 2s, 4s, 8s…), giving the service time to recover
- Jitter: adds a random component to the delay to prevent all clients from retrying at the same time (thundering herd)
- Retry limit: always define a maximum (typically 3-5 retries)
Immediate retry with no limit can make the problem worse by overloading a service that’s already struggling.
Question 8
What are the three pillars of observability?
- A) CPU, memory, and disk
- B) Logs, metrics, and traces
- C) Alerts, dashboards, and reports
- D) Uptime, latency, and throughput
Show answer
Answer: B
The three pillars of observability are:
- Logs: textual records of discrete events (what happened)
- Metrics: numerical values aggregated over time (how much, how fast)
- Traces: tracking a request across multiple services (where it went)
Together, they let you understand the behavior of a distributed system. Alerts, dashboards, and reports are tools that consume this data, but they aren’t pillars in themselves.
Question 9
What is the difference between 99.9% and 99.99% availability?
- A) There’s no practical difference
- B) 99.9% allows ~8.7 hours of downtime per year; 99.99% allows ~52 minutes
- C) 99.99% requires microservices; 99.9% doesn’t
- D) 99.99% is impossible to achieve
Show answer
Answer: B
The difference is significant:
- 99.9% (three nines): ~8.7 hours of downtime per year (~43 minutes per month)
- 99.99% (four nines): ~52 minutes of downtime per year (~4.3 minutes per month)
- 99.999% (five nines): ~5.2 minutes of downtime per year
Each additional “nine” requires exponentially greater investment in redundancy, monitoring, and automation. Most applications don’t need more than three nines.
Section 4: Security
Question 10
Where should authentication be validated in a microservices architecture?
- A) Only in the frontend
- B) In each microservice individually
- C) At the API Gateway, propagating the identity to internal services
- D) Only in the database
Show answer
Answer: C
The recommended pattern is:
- The API Gateway validates the authentication token (JWT, session, etc.)
- If it’s valid, it propagates the user’s identity (userId, roles) to the internal services via headers
- The internal services trust the propagated identity and apply authorization according to their business rules
Validating in every service is redundant and costly. Validating only in the frontend is insecure — the backend must always verify.
Results
Count your correct answers:
| Range | Level | Recommendation |
|---|---|---|
| 9-10 | Advanced | You’re ready for the advanced challenges |
| 7-8 | Intermediate | Good level — review the topics you missed |
| 5-6 | Basic | Go over the fundamentals and patterns sections |
| < 5 | Beginner | Start from the beginning — every section will help |
Don’t worry about the score — what matters is identifying which topics you need to reinforce and going back to the corresponding sections.