Software Architecture interview questions

The actor model builds concurrent systems from actors: independent units with private state that communicate only by sending each other asynchronous messages.

No. An actor is a lightweight object with a mailbox, not an operating system thread. A runtime schedules huge numbers of actors onto a small pool of threads, and an actor uses a thread only while it is handling a message.

Systems with many independent pieces of state that change concurrently: chat and messaging servers, multiplayer game servers, telecom switches, IoT platforms that model each device as an actor, and trading systems. Supervision and location-independent messaging also make it a good fit for fault-tolerant distributed systems.

Asynchronous messages are harder to follow and debug than direct function calls, and a request that needs a reply takes extra plumbing. Delivery guarantees are limited too: across a network a message can be lost, so important messages need acknowledgments or retries.

The adapter pattern is a structural design pattern that wraps an existing class in a new interface, so code expecting one interface can use an incompatible one.

An adapter makes an existing interface match one that clients already expect, usually by wrapping a single class. A facade creates a new, simpler interface over a whole group of classes to make a complex subsystem easier to use.

An adapter changes the interface so incompatible code can work together. A decorator keeps exactly the same interface and wraps an object to add behavior, such as logging or caching.

Hexagonal architecture, also called ports and adapters, applies the same idea at the level of a whole application. The core defines ports as interfaces, and adapters translate between those ports and specific technologies such as a SQL database or a REST API.

Backend for frontend is an architecture pattern in which each kind of client, such as a web or mobile app, gets its own small backend tailored to its needs.

An API gateway is a shared entry point for all clients that handles routing, authentication, and rate limiting. A BFF is a separate backend for one specific client that shapes data for its screens, and BFFs often sit behind a gateway.

It helps when several different clients, such as web and mobile apps, need very different data from the same services, or when frontend teams want to change their API without coordinating with every other team. For a single client with simple needs, one API is usually enough.

Sometimes. GraphQL lets each client request exactly the fields it needs, which solves much of the same problem, but some teams still add a BFF for session handling, security, or client-specific logic.

The builder pattern builds a complex object step by step through a separate builder object, with named steps instead of a long constructor full of arguments.

When an object has many optional parameters, needs validation across several fields, or should be immutable once created. For objects with a few required fields, a constructor is simpler.

A factory decides which object to create and returns it in one call. A builder focuses on configuring one complex object through several steps before creating it.

An API where each method returns the object itself, so calls can be chained into a readable sentence, such as builder.to(...).subject(...).build(). Builders are usually written this way.

The circuit breaker pattern protects a system by stopping calls to a failing dependency for a while and failing fast instead of waiting on timeouts.

Closed means calls flow normally while failures are counted. Open means calls fail immediately without reaching the service. Half-open means a few trial calls are allowed through after a cooldown to check whether the service has recovered.

A retry repeats a failed call in case the problem was temporary. A circuit breaker stops making calls after repeated failures so a struggling service has time to recover; retries usually run inside the breaker, with a growing delay between attempts.

They fail fast, typically with an error the caller can handle, or they return a fallback such as cached data, a default value, or a friendly message. This keeps the caller responsive instead of hanging on timeouts.

Clean architecture is a way of structuring software in layers so that the core business rules never depend on frameworks, databases, or user interfaces.

The dependency rule says code in an inner layer must never depend on anything in an outer layer. Business rules don't import framework or database code; instead, outer layers depend on interfaces that the inner layers define.

They share the same goal of isolating business logic from technical details. Hexagonal architecture describes this as a core surrounded by ports and adapters, while clean architecture adds more explicitly named layers such as entities and use cases.

Often, yes. For small applications or prototypes, the extra interfaces and layers can slow development without much benefit. Many teams start simpler and introduce clearer boundaries as the codebase and its business rules grow.

Client-server architecture splits a system into clients, which request data or actions, and servers, which provide them, as when a browser requests a page.

In client-server, dedicated servers provide services to many clients. In peer-to-peer, every participant can act as both client and server, sharing resources directly without a central server.

Yes. Browsers are clients that request pages and data, and web servers respond over HTTP. Behind them, web servers are often clients of databases and other services.

A client-server design with three layers: the presentation tier in the client, an application tier on the server with the business logic, and a data tier with the database.

Cohesion is a measure of how closely the responsibilities inside a module, class, or service belong together, and high cohesion is a sign of good design.

Cohesion describes how closely related the responsibilities inside one module are, while coupling describes how much different modules depend on each other. Good designs combine high cohesion within modules with loose coupling between them.

Informally, check whether a module has one clear purpose you can describe in a sentence and whether its methods work with the same data. Static analysis tools can also compute metrics such as LCOM (lack of cohesion of methods), which flags classes whose methods share few fields.

The single responsibility principle says a class should have only one reason to change. Following it naturally produces high cohesion, because everything in the class serves the same responsibility.