Architecture
Software Architecture Interview Questions
Software architecture interviews assess whether you can make and justify high-level design decisions — the kind that are expensive to undo six months into a project. Senior engineers and architects are expected to reason about trade-offs between monoliths and microservices, synchronous and asynchronous communication, and different consistency models.
Architectural decisions shape everything that follows: team structure, deployment complexity, testing strategy, and how the system evolves. Knowing the patterns is table stakes; being able to say when not to use them is what separates candidates.
Key Concepts
Monolith vs Microservices
A monolith is a single deployable unit — simple to develop, test, and deploy early on. Microservices split the system into independently deployable services — each with its own database, deployment pipeline, and team. The cost of microservices is significant: distributed systems failures, network latency, eventual consistency, and operational complexity. Don't reach for microservices until the monolith is genuinely painful.
API Design Principles
REST uses HTTP verbs and resource URLs; it's stateless and cacheable, making it a natural fit for public APIs. GraphQL gives clients control over what data they fetch — valuable when many different clients have different data needs. gRPC uses Protocol Buffers and HTTP/2 for low-latency, strongly typed, internal service-to-service communication. Choose based on who the consumer is and what they need.
Event-Driven Architecture
Services communicate by publishing and consuming events rather than calling each other directly. This decouples producers from consumers, enables replay and audit logs, and allows new consumers to be added without changing producers. The downsides: harder to trace a request end-to-end, eventual consistency is the norm, and you need a reliable event broker.
CQRS (Command Query Responsibility Segregation)
Separate the write model (commands that change state) from the read model (queries that return data). This lets you optimise each independently — for example, a normalised write store and a denormalised read store tuned for specific query patterns. Often paired with event sourcing, where state is derived by replaying a log of events.
Layered Architecture
The classic presentation → business logic → data access layering keeps concerns separated. Each layer depends only on the layer below it. Domain-Driven Design adds a domain model layer that encapsulates business rules independently of infrastructure. Hexagonal architecture (ports and adapters) takes this further, making the core domain entirely independent of frameworks and databases.
Resilience Patterns
Distributed systems fail partially. The circuit breaker stops calling a failing downstream service and fails fast instead of queueing requests. Bulkheads isolate failures in one part of the system from the rest. Retries with exponential backoff handle transient failures. Timeouts prevent cascading delays. Know these patterns and be able to say which failure mode each addresses.
Sample Interview Questions
When would you choose a monolith over microservices?
Answer: At the start of a project, when the team is small (< 10 engineers), when the domain isn't well understood yet, or when operational simplicity is a priority. Microservices are justified when independent deployment velocity, fault isolation, or scaling individual components provides concrete value that outweighs the complexity cost.
Why it matters: This question filters out candidates who treat microservices as a default. The right answer acknowledges that context determines the choice.
What is the difference between synchronous and asynchronous communication between services?
Answer: Synchronous (HTTP/gRPC): the caller blocks until the callee responds. Simple to reason about, but the caller is coupled to the callee's availability and latency. Asynchronous (message queue/event bus): the caller publishes a message and continues; the callee processes it later. Decoupled, resilient to downstream failures, but harder to debug and requires handling eventual consistency.
Why it matters: Shows you understand the practical availability and coupling implications, not just the mechanics.
Explain CQRS and when it is worth the added complexity.
Answer: CQRS separates writes and reads into distinct models. It's worth the complexity when read and write workloads have very different scaling or optimisation requirements — for example, a system with complex aggregations for reporting that would be expensive to run against the write store. It's overkill for simple CRUD applications.
Why it matters: Interviewers want to hear 'it depends' backed by concrete criteria, not a definition followed by enthusiasm.
Ready to test yourself?
Apply what you've read with a timed 10-question quiz on Architecture.
Start Architecture Quiz →