Software Architecture

1Monolith vs microservices vs modular monolith

The most over-asked architecture question — and the one most people answer with dogma instead of judgment.

A monolith is one deployable unit. It's simpler to build, test, deploy, and debug — no network between components, no distributed-systems tax. Its weakness shows at scale of team and codebase: everything ships together, a bug anywhere can take down everything, and you can't scale one hot component independently.

Microservices split the system into small, independently deployable services owned by separate teams. The benefits are independent deployment, independent scaling, and fault isolation. But you pay a heavy tax: network latency and failures, distributed transactions, eventual consistency, and a whole operational burden (service discovery, tracing, orchestration). Most teams adopt them too early.

The sophisticated middle is the modular monolith: one deployable, but with strict internal module boundaries. You get monolith simplicity now and a clean seam to extract services later if scale demands it. The senior position is almost always "start with a modular monolith; split out services only when a specific scaling or team-autonomy pressure justifies the distributed-systems cost."

2Layered & MVC

The classic layered architecture separates concerns into horizontal tiers: presentation → business logic → data access → database. Each layer talks only to the one below, so changes stay contained — you can swap the database layer without touching business logic. It's the default for a reason: it's simple and everyone understands it.

MVC (Model-View-Controller) is the same instinct applied to interactive apps: the Model holds data and rules, the View renders, the Controller mediates input. The point of both is the same as encapsulation at the class level (Module 01) — separate concerns so each part has one job and one reason to change. The trap is the "fat controller" or "anaemic model" where logic leaks into the wrong layer.

3Event-driven architecture

Instead of services calling each other directly (synchronous, tightly coupled), event-driven systems communicate by emitting and reacting to events. An OrderPlaced event is published; inventory, email, and analytics services each react independently — and the publisher has no idea they exist. It's the Observer pattern (Module 01) at system scale.

The payoff is loose coupling and extensibility: add a new reaction without modifying the producer. The cost is that flow becomes harder to trace and you inherit eventual consistency — the system is correct eventually, not instantly. Great for decoupling and scale; harder to debug end-to-end.

4Hexagonal / Clean architecture

These styles (Ports & Adapters / Clean / Onion — same core idea) push one principle hard: your business logic should not depend on infrastructure. The domain sits at the centre, knowing nothing about databases, web frameworks, or message brokers. Those external concerns plug in at the edges through interfaces (ports), implemented by adapters.

This is Dependency Inversion (Module 01's "D" in SOLID) scaled to a whole system. The dependencies point inward — infrastructure depends on the domain, never the reverse. The payoff: you can test business logic with no database, and swap Postgres for Mongo or REST for gRPC by writing a new adapter, leaving the core untouched. It's more upfront structure, justified when the domain is rich and long-lived.

5DDD & bounded context

Domain-Driven Design is about modelling software around the real business domain, using a ubiquitous language shared by engineers and domain experts — the code uses the same words the business does. Its most quoted concept is the bounded context: a boundary within which a model and its terms are consistent.

The insight that makes it click: the word "customer" means different things to Sales, Billing, and Support — so forcing one giant shared "Customer" model creates a tangled mess. Bounded contexts let each part of the business have its own coherent model. This is also the soundest way to decide microservice boundaries: draw services along bounded contexts, not arbitrary technical lines.

6CQRS & Event Sourcing

Awareness-level, but worth being able to define cleanly. CQRS (Command Query Responsibility Segregation) separates the write model from the read model — they can use different schemas or even different databases, each optimised for its job. It shines when read and write loads are wildly asymmetric, at the cost of added complexity.

Event Sourcing stores state as an immutable log of events rather than just the current snapshot. Current state is derived by replaying events. You gain a perfect audit trail and the ability to reconstruct any past state — invaluable for finance — but querying current state is harder and the model is more complex. The two are often paired but independent. Know them; don't reach for them casually.

7Caching strategies

Caching trades freshness for speed by keeping hot data closer to the consumer. The strategies you should name:

• Cache-aside (lazy) — app checks the cache; on a miss it loads from the DB and populates the cache. The most common pattern.
• Write-through — writes go to cache and DB together; reads are always fresh, writes a bit slower.
• Write-back — write to cache, flush to DB later; fast writes, risk of loss on failure.

The two hard problems are invalidation (how do you know cached data is stale? — "there are only two hard things in CS...") and eviction (what to drop when full — usually LRU). And mention TTLs. Demonstrating you know caching introduces a consistency problem, not just speed, is the senior signal.

8Load balancing — L4 vs L7

A load balancer spreads traffic across multiple servers so no single one is overwhelmed — the foundation of horizontal scaling and high availability. It also health-checks instances and routes around dead ones.

The distinction interviewers like: L4 (transport layer) balances on IP and port — fast and protocol-agnostic, but it can't see request content. L7 (application layer) understands HTTP, so it can route by URL path, headers, or cookies (e.g. /api to one pool, /images to another), terminate TLS, and do content-based routing — richer, slightly slower. Common algorithms: round-robin, least-connections, IP-hash for stickiness.

9Message queues — Kafka vs RabbitMQ vs SQS

Queues decouple producers from consumers and absorb load spikes — work is buffered and processed at the consumer's pace, so a traffic surge fills the queue instead of crashing the service. They also enable async processing and retries.

The key conceptual split: Kafka is a durable, replayable log (consumers track their own position and can re-read history), whereas a traditional broker like RabbitMQ typically deletes a message once acknowledged. That "log vs queue" distinction is the one to land.

10Resilience — circuit breaker, retry, Saga

In a distributed system, failure is normal, so you design for it. Three patterns recur:

• Retry with backoff — retry a transient failure, but with exponential backoff and jitter so you don't hammer a struggling service. Pair with idempotency (Module 04) so retries are safe.
• Circuit breaker — after repeated failures, "trip" and stop calling a failing dependency for a while, failing fast instead of piling up. This stops one sick service from cascading into a system-wide outage.
• Saga — manages a transaction spanning multiple services without a distributed lock: a sequence of local transactions, each with a compensating action to undo it if a later step fails. It's how you keep consistency across microservices.