Software Architecture Fundamentals

Question 1

Your startup is building its first product. A senior engineer suggests starting with a monolith instead of microservices. Is this good advice?

Accepted Answer

Yes, starting with a monolith is often wise - it's simpler to develop, deploy, and debug; you can extract microservices later when the domain boundaries become clear

Answer

No, microservices are always better for scalability

Answer

It doesn't matter - they're equivalent

Answer

No, monoliths can't scale at all

Question 2

A function fetches data from an API, processes it, saves to database, and sends an email notification. What's the architectural issue?

Accepted Answer

It violates separation of concerns - mixing data access, business logic, and side effects makes it hard to test, maintain, and reuse

Answer

It should use async/await

Answer

Functions should never call APIs

Answer

There's no issue - this is efficient

Question 3

An e-commerce system needs to:
1. Update inventory after order
2. Send order confirmation email
3. Notify shipping service
4. Update analytics

Currently, the order service calls each system synchronously. What's a better approach?

Accepted Answer

Use event-driven architecture - order service publishes an 'OrderPlaced' event, and other services subscribe and react independently

Answer

Make all calls faster with caching

Answer

Combine all services into one for simplicity

Answer

Run calls in parallel threads

Question 4

Your mobile app calls 5 different microservices directly. Users complain about slow load times and you're struggling with authentication in each service. What pattern could help?

Accepted Answer

Implement an API Gateway - a single entry point that handles authentication, aggregates responses from multiple services, and simplifies the client

Answer

Add more servers to each microservice

Answer

Convert to a monolith

Answer

Cache everything on the client

Question 5

You're splitting a monolith into microservices. The monolith uses a shared PostgreSQL database. Should each microservice have its own database?

Accepted Answer

Yes, each service should own its data - this ensures loose coupling, allows different database types per service, and prevents cascading failures

Answer

No, one database is simpler and enables JOINs across services

Answer

Only some services need their own database

Answer

Use a distributed database like CockroachDB instead

Question 6

Your application has complex read queries that slow down writes. Reads need denormalized data for performance, but writes need normalized data for consistency. What pattern addresses this?

Accepted Answer

CQRS (Command Query Responsibility Segregation) - separate read and write models, optimizing each for its purpose

Answer

Add more indexes to the database

Answer

Use a faster database

Answer

Cache all queries

Question 7

Service A calls Service B, which is experiencing failures. Service A keeps retrying, causing its own response times to spike and eventually crash. What pattern prevents this cascade?

Accepted Answer

Circuit Breaker - after repeated failures, stop calling Service B temporarily, return a fallback response, and periodically check if B has recovered

Answer

Retry with exponential backoff

Answer

Add a timeout to all requests

Answer

Duplicate Service B for redundancy

Question 8

Your OrderService directly instantiates a StripePaymentProcessor. Now you need to add PayPal support and write unit tests without hitting payment APIs. What principle should guide the refactor?

Accepted Answer

Dependency Inversion - high-level modules should depend on abstractions (interfaces), not concrete implementations

Answer

Single Responsibility Principle

Answer

Don't Repeat Yourself (DRY)

Answer

Keep It Simple (KISS)

Question 9

Your web application is hitting performance limits. You can either upgrade to a more powerful server (32 cores, 128GB RAM) or deploy multiple smaller instances behind a load balancer. Which approach is generally preferred for web applications?

Accepted Answer

Horizontal scaling (more instances) - provides redundancy, no single point of failure, and theoretically unlimited capacity

Answer

Vertical scaling (bigger server) - simpler to manage

Answer

They're equivalent, just pick cheaper option

Answer

Use both at maximum

Question 10

A booking service needs to: reserve flight, reserve hotel, charge payment. If payment fails, hotel and flight must be cancelled. In a microservices world, how do you handle this distributed transaction?

Accepted Answer

Saga pattern - a sequence of local transactions where each step has a compensating action; if a step fails, execute compensations in reverse order

Answer

Use a distributed database transaction

Answer

Hope all services succeed

Answer

Put everything in one service