Software Architecture interview questions and answers

Question 1

What is software architecture, and why does it matter?

Accepted Answer

Software architecture is the set of big, early decisions about how a system is split into parts, how those parts talk to each other, and where each part runs. It is the shape of the system, not the details inside one function. It matters because these decisions are the hardest and most expensive to change later. You can rename a variable in a minute. Splitting one program into twenty services, or merging twenty back into one, can take a team months. Good architecture makes the changes you expect cheap, keeps parts loosely connected so a change stays local, and lets the system grow with the traffic and the team. Analogy: the layout of a house versus the furniture. Moving a sofa is easy. Moving a load-bearing wall or the plumbing stack is a renovation. Architecture is the walls and the plumbing. In an interview: I describe architecture as the decisions that are expensive to reverse: how the system is divided, how the pieces communicate, and where they run. The goal is to make expected change cheap and keep the pieces loosely coupled.

Question 2

What are coupling and cohesion, and why do they matter for architecture?

Accepted Answer

Coupling is how much one part depends on another part. Low coupling means you can change or deploy one part without touching the others. High coupling means a small change ripples outward. Cohesion is how well the things inside one part belong together. High cohesion means a part has one clear job. Low cohesion means it is a grab bag of unrelated work. Every architecture style in this topic is really an attempt at the same goal: high cohesion inside each part, low coupling between parts. Microservices, layering, and event-driven design are all different ways to draw those boundaries. If you draw them in the wrong place you get the worst of both: parts that must be changed and deployed together but live in separate repositories. Analogy: a well-run office. Each team owns one clear area (cohesion) and can do its work by sending a short request to another team rather than sitting in on their meetings (loose coupling). In an interview: Coupling is how much parts depend on each other, cohesion is how focused each part is. I judge any architecture by whether it gives high cohesion within a boundary and low coupling across it.

Question 3

What is the difference between scaling up and scaling out?

Accepted Answer

Scaling up, also called vertical scaling, means giving one machine more power: more CPU, more memory, a faster disk. It is simple because the code does not change, but there is a ceiling on how big one machine can get, and big machines cost a lot more per unit of power. Scaling out, also called horizontal scaling, means adding more machines and spreading the work across them behind a load balancer. There is almost no ceiling, and you can use cheap commodity machines, but the code has to support it: the app should be stateless so any machine can handle any request, and the data layer has to cope with many readers and writers. A monolith is usually scaled up, or scaled out as whole copies. Microservices let you scale out just the one service that is under load. Analogy: moving house. Scaling up is knocking through to add a bigger room. Scaling out is buying the flat next door and the one down the road, then hiring someone to direct people to whichever one has space. In an interview: Scaling up is a bigger box, scaling out is more boxes behind a load balancer. Up is simplest but capped, out is unlimited but needs stateless app code and a data layer that can handle it.

Question 4

What is the difference between synchronous and asynchronous communication?

Accepted Answer

Synchronous means the caller sends a request and waits, doing nothing else, until the reply comes back. A normal HTTP API call is synchronous. It is simple to reason about, but the caller is now coupled to the callee being up and fast. If service B is slow, service A is slow too, and if B is down, A fails. Asynchronous means the caller sends a message and moves on. Something else picks the message up later and processes it. The caller does not wait and does not need the receiver to be up right now. This gives loose coupling and resilience, but it is harder: you have to handle messages arriving out of order, arriving twice, or being processed much later, and there is no immediate answer to return to a user. Analogy: synchronous is a phone call: both people must be free at the same time and you wait for the answer. Asynchronous is a text message: you send it and carry on, they reply when they can. In an interview: Synchronous is call and wait, asynchronous is send and forget. Synchronous is simpler but couples availability and latency. Asynchronous through a broker decouples services at the cost of eventual consistency and harder debugging.

Question 5

What is a monolithic architecture?

Accepted Answer

A monolith is an application built and shipped as one single unit. The user interface code, the business logic, and the data access code all live in one codebase, are compiled or packaged together, and run as one process (or as several identical copies of that one process). There is usually one shared database. This is the traditional way to build software and it is still the right starting point for most projects. 'Monolith' is not an insult. It only becomes a problem when the codebase and the team grow past the point where one unit is manageable. Analogy: a Swiss Army knife. Every tool is in one handle. Very convenient to carry and use, until you have fifty tools bolted on and opening one bends another. In an interview: A monolith is the whole application as one build, one deployment, one process, usually one database. I always add that it is a perfectly good default, not a mistake, and the real question is when to break it up.

Question 6

What are the advantages and disadvantages of a monolith?

Accepted Answer

Advantages come from everything being in one place. It is simple to develop, test, and deploy. A call from one part to another is just a function call, so it is fast and easy to debug: one codebase, one log, one stack trace, one debugger. You do not have to think about network failures between your own components. Disadvantages come from size. As it grows the codebase gets hard to understand and change. You cannot scale one busy feature on its own, you have to run more copies of the whole thing. Adopting a new language or framework for one part is hard because it is all wired together. Every release redeploys everything, so a small change carries the risk of the whole app, and a big team stepping on the same codebase slows down. Analogy: living in one big open-plan room. Great when you are one or two people: everything is to hand. Painful with ten housemates: you cannot renovate the kitchen without disturbing everyone, and one person's mess is everyone's mess. In an interview: The monolith trades away independent scaling and independent deployment to buy simplicity: fast local calls, one place to look when something breaks, and an easy build. Those simplicity gains are large early and shrink as the system and team grow.

Question 7

When is a monolith the right choice, and what are real examples?

Accepted Answer

Start with a monolith when the team is small, the product is still changing shape, and you do not yet know where the natural boundaries are. You move faster without the overhead of a distributed system, and you learn the domain, which tells you where to split later if you ever need to. Real examples: most early-stage startups, internal business tools, content management systems like WordPress, and many large enterprise systems (CRM and ERP products) that began life as monoliths. Plenty of large, successful products are still mostly monolithic. Shopify and Basecamp are well known for running large monoliths on purpose. Analogy: cooking for a dinner party of four in your home kitchen versus building a restaurant with separate stations. For four people, one kitchen is faster and cheaper. You only build the stations when you are feeding hundreds. In an interview: I default to a monolith for a small team or a young product, because you do not yet know the right service boundaries and the distributed-systems tax is not worth paying. Split later, driven by real pain, not by fashion.

Question 8

What is client-server architecture?

Accepted Answer

Client-server splits a system into two roles that usually run on different machines. The client is the part the user interacts with. It shows the interface and sends requests. The server receives those requests, runs the logic, manages the data, and sends responses back. One server typically handles many clients at once. Almost every networked app you use is client-server: a web browser and a web server, a mobile app and its backend, an email client and a mail server. It is a foundational pattern rather than a competing style, and the other styles here describe how the server side is built. Analogy: a restaurant. You (the client) place an order with the waiter. The kitchen (the server) does the cooking and sends the food back. Many tables share one kitchen. In an interview: Client-server is the split between the user-facing part that makes requests and the shared backend that processes them and owns the data. It is the base pattern for web and mobile, and the server side is where the other architecture styles apply.

Question 9

What does the client do and what does the server do?

Accepted Answer

The client's job: render the interface, capture what the user does, do light validation, and send requests for data or actions. Clients come in many forms: browsers, mobile apps, desktop apps, other services, IoT devices. The server's job: authenticate the caller, enforce the real business rules, read and write the database, do heavy computation, and return a response. The server is trusted; the client is not, because anyone can tamper with code running on their own device. So security-sensitive checks and the source of truth always live on the server. Servers usually run on stronger hardware and are built to handle many clients at the same time. Analogy: a bank branch. You fill in a slip (client: gather input, basic checks). The teller verifies your identity, checks your balance, and moves the money (server: real rules, real data). You are never allowed behind the counter. In an interview: Client gathers input and shows results, server holds the rules and the data. The key line is that the client is untrusted, so every check that matters and the single source of truth stay on the server.

Question 10

What are the trade-offs of client-server, and what are examples?

Accepted Answer

Advantages: the server can be scaled and updated on its own without changing every client, data lives in one managed place so it stays consistent, and sensitive logic stays off the user's device. Disadvantages: the client needs a network connection, so the app is at the mercy of connectivity, and latency between client and server is always there. The server can become a bottleneck or a single point of failure if it is not designed to scale and to have redundancy. Building and running two sides is more work than a single local program. Examples: any website (browser and web server), email (client and IMAP or POP server), online banking, video streaming like Netflix, and multiplayer online games where the game client talks to a game server. Analogy: electricity from the grid versus a generator in your garden. The grid (server) is professionally run, shared, and always improving, but if the line to your house is cut you have nothing. In an interview: You gain central control of data and logic and the ability to evolve the server independently. You pay with a hard dependency on the network and the need to make the server scalable and redundant so it is not a single point of failure.

Question 11

What is layered, or n-tier, architecture?

Accepted Answer

Layered architecture organises the code inside an application into horizontal layers, each with one kind of responsibility. A typical set is: presentation (handles requests and responses), business or application logic (the rules), and data access (talks to the database). Each layer only calls the layer directly below it and only serves the layer directly above it. This is a way of structuring code, and it fits inside other styles. A monolith is usually layered internally. A single microservice is often layered internally too. Analogy: a company's chain of command. The front desk talks to the department, the department talks to the warehouse. The front desk does not walk into the warehouse and start moving boxes. In an interview: Layered architecture stacks the code by responsibility, presentation over logic over data access, with each layer calling only the one below. It is a code-organisation pattern that lives inside a monolith or a single service, not a deployment style.

Question 12

What are the usual layers and the rules between them?

Accepted Answer

Presentation layer: receives input (an HTTP request, a screen event), formats output. It should contain no business rules. Business or application layer: the actual rules and workflows. It does not know it is being called from the web, and it does not know which database is underneath. Data access layer: turns business objects into database reads and writes and back. It hides the specific database. Rules: calls flow downward only. A lower layer never calls up. Skipping a layer (presentation reaching straight into data access) is usually discouraged because it spreads knowledge that should be in one place. Keeping to these rules means you can rewrite the data layer, or add a second presentation layer like a mobile API, without disturbing the business rules. Analogy: ordering room service in a hotel. You (presentation) call the front desk. The desk (logic) decides what is allowed and coordinates. The kitchen and housekeeping (data access) actually fetch things. You never call the kitchen directly. In an interview: Three layers: presentation, business logic, data access, with dependencies pointing down. The payoff is that the business rules do not know about HTTP or SQL, so you can change either end without rewriting the middle.

Question 13

What are the trade-offs of layered architecture?

Accepted Answer

Advantages: clear separation of concerns, so the code is easier to understand, test, and change one slice at a time. Layers and their pieces can be reused, and you can optimise or scale a layer on its own. Disadvantages: it can become rigid. A simple feature sometimes forces a change in every layer (add a field: touch the screen, the service, the repository, the table). Passing a request down through several layers adds a little overhead and a lot of near-identical 'pass-through' code. And a strict layered design is not always the fastest option, because data is copied and transformed at each boundary. Analogy: a bucket brigade passing water down a line. Very organised and everyone knows their job, but the water is slower than one person with a hose, and adding a new instruction means telling every person in the line. In an interview: Layering buys separation of concerns and testability. It costs boilerplate and rigidity, since a change can ripple through every layer, and the indirection has a small performance price.

Question 14

What is MVC architecture?

Accepted Answer

Answer: MVC (Model-View-Controller) splits an application into three parts so that the data, the display, and the request handling do not get tangled together. Model: the data and the business rules. It knows nothing about the screen. View: what the user sees. It just renders whatever the model gives it and has no logic. Controller: receives the user's request, tells the model what to do, then picks a view to show the result. The flow: request goes to the controller, the controller updates or reads the model, then hands data to the view, which renders the response. Because the three parts are separate, you can change the look without touching the rules, and test the rules without a browser. Analogy: a restaurant. The kitchen and recipes are the model, the plated dish on the table is the view, and the waiter who takes your order and brings the food is the controller. In an interview: MVC separates the data and rules (Model), the display (View), and the request handling (Controller). Requests hit the controller, which drives the model and selects a view. It keeps presentation and logic independent and testable. MVVM and MVP are variants.

Question 15

What is a microservices architecture?

Accepted Answer

Microservices break an application into a set of small services that are each built around one business capability, run as their own process, and are deployed on their own. Services talk to each other over the network through clear APIs, usually HTTP or messages. Each service ideally owns its own database, so no other service can reach into its data directly. The point is independence. A team can build, deploy, scale, and even rewrite one service without coordinating a release with everyone else. The cost is that you now have a distributed system, with all the network failures, data consistency problems, and operational tooling that implies. Analogy: a food court instead of one big restaurant. Each stall has its own kitchen, its own menu, its own staff, and its own till. One stall can close for cleaning or change its menu without shutting the whole court. In an interview: Microservices split the system by business capability into independently deployable services, each with its own database, talking over the network. The prize is independent deployment and scaling per team and per service. The price is that you own a distributed system.

Question 16

What are the advantages of microservices?

Accepted Answer

Independent deployment: a change to one service ships without a full-system release, so teams release often and with less risk. Independent scaling: if checkout gets hammered on a sale day, you run more copies of the checkout service only, not the whole app. Team autonomy: one team owns a service end to end and is not blocked by others. Technology choice per service: a service that does machine learning can use Python while the rest use Java. Resilience by design: if the recommendations service is down, the site can still show products without recommendations, rather than failing completely. Easier to understand one service: each codebase is small and focused. Analogy: a city with independent utilities. The water company can dig up one street without asking the electricity and gas companies, and if one substation fails the whole city does not go dark. In an interview: The headline advantages are independent deployment and independent scaling, plus team autonomy and the freedom to pick the right technology per service. Resilience is possible but only if you design for graceful degradation.

Question 17

What are the disadvantages and hard parts of microservices?

Accepted Answer

Network overhead: calls that used to be instant function calls are now network requests that can be slow, fail, or time out. You have to design for that everywhere. Data consistency: there is no single database and no easy cross-service transaction. Keeping data in step across services means eventual consistency, sagas, and compensating actions. Operational complexity: many services means you need deployment automation, service discovery, centralised logging, distributed tracing, and monitoring, or you are flying blind. Coordinating a change across services is painful, especially an API or data-shape change that several services depend on. Upfront cost: the tooling and infrastructure take real effort before you ship a single feature. A small team drowns in it. Analogy: turning one household into ten separate flats. Now every shared decision needs a meeting, the plumbing between flats can leak, and you need a building manager, cameras, and an intercom just to keep it running. In an interview: The hard parts are the network (latency and partial failure), data consistency without a shared transaction, and the operational tooling you must build. The classic failure is a distributed monolith, where services are separate but still have to be deployed together.

Question 18

Why should each microservice own its own database?

Accepted Answer

If two services share a database, they are secretly coupled through the table structure. One team changing a column can break another team's service with no warning, and neither service can be deployed or scaled truly independently. You are back to a monolith, just with extra network calls. So each service gets its own database that only it can touch. Other services ask for data through that service's API, never by querying its tables. The downside is real: data that used to be one JOIN is now spread across services, so you either call several services and combine the results, or you keep a local read-only copy that is updated by events, which is eventually consistent. Analogy: flatmates sharing one fridge versus each having their own. Shared fridge: someone reorganises it and you cannot find your food, and you cannot move out with your groceries. Own fridge: you are independent, but making a shared meal takes more coordination. In an interview: Shared databases recreate tight coupling through the schema, so you lose the independence that is the whole point. Database per service restores it, at the cost of no cross-service JOINs, which you replace with API calls or event-driven read copies.

Question 19

What are real examples of microservices, and what do they tell us?

Accepted Answer

Netflix runs hundreds of services for things like authentication, recommendations, streaming, and billing, so it can scale each independently for a global audience. Amazon's retail site is many services: catalog, orders, payments, recommendations. Uber splits ride requests, driver matching, pricing, payments, and tracking into separate services. Airbnb, Spotify, and eBay are similar. What this tells us: microservices pay off at large scale, with many teams, and with clearly different scaling needs per feature. Every one of these companies started smaller and moved to microservices when the monolith actually hurt. The lesson is not 'build microservices', it is 'split when the pain is real and you know where the seams are'. Analogy: big airports have separate terminals per airline alliance. It only makes sense at that passenger volume. A regional airport with one terminal would waste money copying it five times. In an interview: Netflix, Amazon, Uber, Airbnb, Spotify all run microservices, and all of them grew into it from a monolith. The takeaway is that microservices are an answer to scale and organisational size, adopted when the monolith genuinely stops working.

Question 20

What is SOA, and how is it different from microservices?

Accepted Answer

Service-oriented architecture is an older style, from the 2000s, built on the same idea: a system as a set of reusable, loosely coupled services with well-defined interfaces. It was popular in large enterprises for integrating many existing systems. The differences are about size and plumbing. SOA services tend to be larger and coarser, often sharing databases, and they usually communicate through a heavy central component called an enterprise service bus (ESB) that does routing, transformation, and orchestration. Microservices are smaller, own their data, avoid a smart central bus in favour of simple messaging or HTTP, and put the logic in the services ("smart endpoints, dumb pipes"). You can think of microservices as SOA's lessons applied with lighter tooling and stricter boundaries. Analogy: SOA is a big organisation where every request goes through a central mailroom that sorts, translates, and forwards it. Microservices is teams that email each other directly using a shared, simple format. In an interview: SOA and microservices share the goal of loosely coupled reusable services. SOA uses fewer, larger services and a smart central bus. Microservices use many small services, a database each, and dumb pipes with smart endpoints.

Question 21

What is event-driven architecture?

Accepted Answer

In event-driven architecture, parts of the system communicate by producing and reacting to events. An event is a small message that says something happened, for example 'OrderPlaced' or 'PaymentFailed'. A component that notices something publishes an event to a central broker. Other components that care about that event have subscribed to it and react in their own way. The producer does not know or care who is listening. You can add a new consumer, for example an analytics service, without changing the producer at all. Communication is usually asynchronous, so the producer does not wait for consumers to finish. Analogy: a public address announcement in a building. Someone says 'the 3pm meeting is moved to room 4'. Everyone who cares reacts in their own way. The announcer does not phone each person and wait for them to act. In an interview: Event-driven architecture has components publish events about things that happened and other components subscribe and react, through a broker, usually asynchronously. The producer does not know its consumers, so you add reactions without touching the source.

Question 22

What are events, producers, consumers, and the broker?

Accepted Answer

Event: a record that something happened, named in the past tense, carrying the data about that fact. 'ItemShipped' with an order id and a timestamp. Producer (or publisher): the component that detects the thing and emits the event. It could be a user action, a sensor, or another service. Consumer (or subscriber): a component that has registered interest in certain events and has an event handler, a piece of code that runs when one arrives. A consumer might update its own data, call another system, or publish a new event. Broker (or event bus): the middle component that receives events from producers and delivers them to the right consumers. It decouples the two sides, buffers events if a consumer is slow or down, and often keeps events organised into topics or channels. Kafka, RabbitMQ, and cloud services like SNS or SQS are common brokers. Analogy: a newspaper delivery system. Reporters file stories (producers). The distribution centre (broker) sorts them by section. Subscribers get only the sections they signed up for and read them how they like (consumers with handlers). In an interview: An event is a past-tense fact with data. Producers emit them, consumers subscribe and run a handler, and the broker sits in the middle routing and buffering so the two sides never talk directly.

Question 23

What is the publish-subscribe model, and why does asynchronous processing matter here?

Accepted Answer

Publish-subscribe means producers publish events to a named topic, and any number of consumers subscribe to that topic and each receive a copy. The producer does not address a specific consumer, and it does not know how many there are. This is different from a queue, where each message goes to exactly one worker. Asynchronous processing is what makes this loose coupling real. Because the producer does not wait for consumers, it is not slowed down by a slow consumer and does not fail when a consumer is down. Events pile up in the broker and are processed when the consumer is ready. The trade-off is that the effect of an event is not immediate, so the system is eventually consistent, and you must handle events that arrive twice or out of order. Analogy: a group chat versus a direct message. In the group (pub-sub) you post once and everyone interested sees it, replying in their own time. A slow replier does not stop you posting. In an interview: Pub-sub is publish to a topic, every subscriber gets a copy, producer addresses nobody. Async delivery through the broker is what buys the decoupling and spike smoothing, and it costs you eventual consistency and the need for idempotent consumers.

Question 24

What are the trade-offs of event-driven architecture, and what are examples?

Accepted Answer

Advantages: very loose coupling, easy to add new reactions, good for real-time responsiveness, and it smooths out load spikes because the broker buffers work. Disadvantages: the flow of control is hard to see. There is no single call stack to read. Following what happens after 'OrderPlaced' means tracing through several services and the broker. Testing and debugging are harder because everything is asynchronous. Too many fine-grained events create their own overhead. And keeping correct ordering and consistency across many consumers is genuinely difficult. Examples: IoT systems reacting to sensor data, trading platforms reacting to market ticks, real-time analytics like live sports stats, e-commerce order pipelines, and notification or alerting systems. Analogy: a domino run. Beautiful when it works, and easy to add another branch. But when it stops halfway you have to walk the whole line to find the domino that did not fall. In an interview: Event-driven buys extreme decoupling, easy extension, and spike absorption. It costs you visibility: there is no single stack trace, so you lean hard on distributed tracing, and you have to design consumers to be idempotent and tolerant of ordering.

Question 25

What is serverless, or Function as a Service?

Accepted Answer

Serverless means you write small functions and hand them to a cloud provider, and the provider runs them for you. You do not create servers, patch them, or decide how many to run. When a trigger fires, an HTTP request, a file upload, a database change, a timer, the platform starts your function, runs it, and shuts it down. If a thousand requests arrive at once, the platform runs a thousand copies. You pay only for the time your code actually runs. There are still servers. You just do not manage them. AWS Lambda, Azure Functions, and Google Cloud Functions are the common platforms. Analogy: a taxi versus owning a car. You do not buy, insure, park, or maintain anything. You call for a ride, pay for that trip only, and when you are done it drives off to serve someone else. In an interview: Serverless is writing functions and letting a cloud platform run and scale them on demand, triggered by events, billed per execution. The servers exist, you just never touch them.

Question 26

What are the key characteristics of serverless?

Accepted Answer

Event-driven: a function only runs when a trigger fires. It is not a process sitting and listening. Stateless: a function keeps nothing between runs. Anything it needs comes in as input or is fetched from a database or cache. The next run might be on a completely different machine. Auto-scaling: the platform runs as many copies as there are events, from zero to thousands, with no configuration. Pay-per-use: you are billed for the number of runs and the compute time and memory they used. Idle costs nothing. Short-lived: functions are meant to finish quickly, within seconds to a few minutes. Long jobs do not fit. Managed infrastructure: provisioning, scaling, load balancing, and patching are the provider's problem. Analogy: motion-sensor lights in a corridor. They switch on only when someone walks past (event-driven), do not remember previous people (stateless), every fixture lights independently (auto-scaling), and you pay only for the seconds they are on (pay-per-use). In an interview: The six characteristics: event-driven, stateless, auto-scaling, pay-per-use, short-lived, fully managed. The stateless and short-lived parts are the ones that shape how you have to write the code.

Question 27

What are the trade-offs of serverless, and what is a cold start?

Accepted Answer

Advantages: almost no operations work, automatic scaling, you pay nothing when idle, and you can ship a function fast without a deployment pipeline for servers. Disadvantages: a cold start is the delay the first time a function runs, or runs again after being idle, while the platform loads your code and starts a runtime. It can add tens to hundreds of milliseconds, or more for heavy runtimes, which matters for user-facing latency. Functions also have limits on memory, CPU, and how long they can run. State between calls is awkward, so you push it into a database. And serverless ties you closely to one provider's triggers and services, which makes moving away hard (vendor lock-in). Analogy: the motion-sensor light again. A cold start is the half-second flicker before it comes fully on. If you walk past constantly it stays warm and instant. If nobody has been by for an hour, you get the flicker. In an interview: Serverless trades control for zero ops and pay-per-use. The costs to name are cold-start latency, hard resource and time limits, no in-process state, and strong vendor lock-in.

Question 28

When is serverless a good fit, and what are examples?

Accepted Answer

Good fit: workloads that are spiky or unpredictable, short tasks, glue code between services, and anything event-triggered. It shines when traffic is uneven, because you pay nothing during the quiet times and it scales up on its own during the bursts. Poor fit: steady high-volume traffic (a dedicated server is cheaper per request), long-running jobs, workloads that need very low and predictable latency, or anything needing lots of in-memory state. Examples: HTTP APIs with uneven traffic, resizing an image after it is uploaded, processing a stream of events, scheduled jobs like nightly reports or backups, and chatbot backends that respond to messages. Analogy: renting a hall for occasional events versus owning premises for a shop open every day. Occasional use: rent it, pay per event. Daily use: owning is cheaper and always ready. In an interview: Serverless fits spiky, short, event-driven work where scale-to-zero saves money and auto-scaling handles the bursts. It does not fit steady heavy traffic, long jobs, or latency-critical paths.

Question 29

Monolith or microservices: how do you decide?

Accepted Answer

Start from the team and the problem, not from what is fashionable. Choose a monolith when the team is small, the domain is still being learned, and one deployable unit is manageable. Choose microservices when you have several teams that keep blocking each other on releases, when different parts of the system have very different scaling needs, or when the codebase has genuinely grown too big to reason about. The honest default is to start with a monolith, keep clean internal boundaries, and split off a service only when you feel a specific, repeated pain that a split would fix. Splitting early, before you understand the domain, usually puts the boundaries in the wrong place, and moving a boundary between services is far harder than moving one inside a monolith. Analogy: you do not build a road network for a village. You build one wide road, watch where people actually walk, and add roads where the paths are worn. Same with service boundaries. In an interview: I decide on team size, differing scaling needs, and real deployment pain, not on trend. Default to a well-structured monolith and extract services only when a concrete, recurring problem justifies it.

Question 30

What is a modular monolith, and why do people recommend starting there?

Accepted Answer

A modular monolith is a single deployable application that is strictly organised inside into modules with clear boundaries. Each module owns its data and exposes a defined interface, and other modules must go through that interface, not reach into its tables or internals. It is still one build, one process, one deployment. People recommend it because it gives you most of the benefits of good boundaries, cohesion and low coupling, without the distributed-systems cost. And if a module later needs to become its own service, the boundary is already there, so the extraction is mechanical rather than a redesign. You get microservices-ready code without paying for microservices until you need to. Analogy: building a house with well-defined rooms and doorways, rather than one open space. You still live in one house, but if you ever need to wall a room off into a separate flat, the wall is already mostly there. In an interview: A modular monolith is one deployment with hard internal module boundaries and data ownership. It captures the design benefits of microservices while staying simple to run, and it leaves clean seams if you ever need to extract a service.

Question 31

How do microservices and event-driven architecture fit together?

Accepted Answer

They are often used together. Microservices need to communicate, and doing it all with synchronous HTTP calls creates chains where one slow or failed service breaks a whole request. Using events instead lets services stay independent: the Order service publishes 'OrderPlaced', and Payment, Email, and Shipping each react on their own. The Order service does not wait for them and does not fail if one is down. Events also solve the no-shared-database problem. A service can keep its own local copy of the data it needs, kept up to date by subscribing to events from the service that owns that data. That is eventually consistent, but it removes a synchronous dependency. The cost is the same as event-driven anywhere: harder to trace, eventual consistency, and consumers must be idempotent. Analogy: a company where teams email each other updates instead of sitting in every meeting. Each team acts on the updates it cares about, and nobody is blocked waiting in a room. In an interview: Events let microservices communicate without synchronous chains, so services stay independent and resilient, and they let each service keep an eventually-consistent local copy of data it does not own. It is the common pairing, with the usual event-driven trade-offs.

Question 32

What is Conway's law, and how does it affect architecture?

Accepted Answer

Conway's law says that a system's structure ends up mirroring the communication structure of the organisation that built it. Three teams tend to produce three major components, with the seams falling on the gaps between teams. For architecture this cuts both ways. If you impose a service split that does not match how teams are organised, every change needs cross-team coordination and the design fights the org chart. The 'inverse Conway manoeuvre' is to first organise teams around the capabilities you want as services, so the architecture you want emerges naturally. In short: you cannot design the system without also thinking about team boundaries. Analogy: a group project where each person writes one chapter. The report's structure will follow the people, not some ideal outline, no matter what the plan said. In an interview: Conway's law is that architecture mirrors org communication structure. The practical consequence is that a service design only works if it lines up with team boundaries, so you often have to change the teams to get the architecture.

Question 33

What common mistakes do teams make when moving to microservices?

Accepted Answer

Splitting too early, before the domain is understood, so the boundaries are wrong and constantly move. Making services too small, so a single user action fans out into dozens of network calls. Keeping a shared database, which leaves the services tightly coupled through the schema. This is the 'distributed monolith': all the operational cost, none of the independence. Skipping the platform work: no automated deploys, no centralised logging, no distributed tracing, no monitoring, so nobody can see what the system is doing. Using synchronous calls everywhere, creating long fragile chains. Ignoring data consistency, assuming a cross-service operation will behave like a database transaction when it will not. Analogy: demolishing your house into separate huts before deciding where the kitchen and bathroom should go, then discovering every meal needs a walk across the garden in the rain. In an interview: The big ones are splitting too early, keeping a shared database, skipping the observability and deployment tooling, and assuming distributed calls behave like local transactions. Each one gives you the costs of microservices without the benefits.

Question 34

How would you design an API-first system, for example a library management system?

Accepted Answer

Answer: A clear structure to talk through: 1. Clarify scope and scale. How many books, members, branches? Read-heavy or write-heavy? Just browse and borrow, or also reservations and fines? 2. Model the core entities. Book (title, author), BookCopy (a physical copy with a status), Member, Loan (copy, member, due date), Reservation. 3. Design the API around resources. GET /books?q=, GET /books/{id}, POST /loans, POST /returns, POST /reservations. Use proper status codes and pagination. 4. Handle the tricky rules. Only one active loan per copy (a unique constraint or a transaction), due dates and fines, a member's borrowing limit, and a reservation queue when all copies are out. 5. Non-functionals. Caching for the book catalogue (read-heavy), a relational database for loans (needs transactions), and an event or job for overdue notices. Analogy: the interviewer wants to see structure: clarify, model the data, shape the API around resources, then reason about the edge cases and the read/write pattern. In an interview: Clarify scope and scale, model the entities (Book, BookCopy, Member, Loan, Reservation), design the API around those resources with status codes and pagination, then reason through the rules: one loan per copy via a transaction, limits, fines, and a reservation queue.

Question 35

How would you design a frontend that lets multiple products share common features?

Accepted Answer

Answer: Pull the shared parts out into their own versioned packages, and let each product depend on them. The usual layers, from lowest to highest: 1. Design tokens: colours, spacing, fonts as a shared config. 2. UI component library: buttons, inputs, modals, built once, published as a package, documented (Storybook). 3. Shared logic packages: auth, API client, feature flags, analytics, i18n. 4. Product apps: each product is its own app that imports the packages above and adds its own screens. Keep it all in one repository (a monorepo with pnpm/Turborepo/Nx) so changes to a shared package can be tested against every product in one pull request. Version the shared packages so a product can upgrade on its own schedule. The goal: one place to fix a bug in the button, and every product gets it. Analogy: a car maker does not design a new steering wheel for every model. There is a parts catalogue, and each model is assembled from shared parts plus its own body. In an interview: Extract the shared parts into versioned packages: design tokens, a UI component library, and shared logic like auth and the API client. Each product is its own app that composes those packages. Keep it in a monorepo so a change to a shared package is tested against every product at once.

Question 36

What is a micro frontend, and when would you choose it over a single frontend app?

Accepted Answer

Answer: A micro frontend is the same idea as microservices, applied to the browser. Instead of one big frontend codebase, you split the UI into independent pieces, each owned by a different team, each built and deployed on its own, and stitched together at runtime (or build time) into one page. How they are combined: a container app loads each micro frontend, often as a separate JavaScript bundle, via an approach like Module Federation, web components, or an iframe per section. Choose it when: you have several teams that keep blocking each other on one frontend release, the app is very large, and different sections have genuinely different release cadences (for example a checkout team and a search team shipping independently). Do NOT choose it for a small team or a small app. It brings real cost: shared dependency management, consistent styling across independently built pieces, cross-app communication, and more complex builds and routing. For most products a well-structured single app (a modular monolith frontend) is better. Analogy: a shopping mall where each shop fits out and runs its own unit, versus one big department store run by a single staff. The mall model only pays off when you have many independent shopkeepers. In an interview: Micro frontends split the UI into independently built and deployed pieces owned by different teams, combined at runtime by a shell app. Choose it when multiple teams are blocking each other on one frontend and sections have different release needs. For a small team it is overhead with no payoff, so a modular single app is better.

Question 37

How do you decide between server-side rendering, static generation, and client-side rendering for a page?

Accepted Answer

Answer: Match the strategy to how the page's data behaves. Static generation (SSG): render the page to HTML at build time. Best for content that is the same for everyone and rarely changes: marketing pages, docs, blog posts. Fastest possible, cacheable on a CDN, but you must rebuild to update. Incremental static regeneration (ISR): static, but the server rebuilds a page in the background every N seconds or on demand. Good for content that changes occasionally, like a product catalogue. Server-side rendering (SSR): render fresh HTML on every request. Best for pages that are personalised or must be up to the second, and still need to be indexable or fast to first paint: a logged-in dashboard, search results, a price that changes constantly. Costs server work per request. Client-side rendering (CSR): ship a near-empty HTML shell and let JavaScript fetch and render. Fine for private, highly interactive screens behind a login where SEO does not matter, like an app's internal settings page. Questions to ask: does it need SEO? Is the data per-user? How fresh must it be? How often does it change? Analogy: SSG is printing a poster once. ISR is reprinting it every morning. SSR is writing a fresh note for each visitor. CSR is handing the visitor a pen and the facts and letting them write it themselves. In an interview: Decide by the data: same for everyone and rarely changing is static generation; changes occasionally is incremental regeneration; personalised or must-be-live with an SEO or first-paint need is server rendering; private and interactive with no SEO is client rendering. The deciding questions are SEO, per-user data, and freshness.

Software architecture interview preparation

Architecture basics

Monolithic architecture

Client-server architecture

Layered (n-tier) architecture

Microservices architecture

Service-oriented architecture (SOA)

Event-driven architecture

Serverless (Function as a Service)

Frontend architecture

Choosing an architecture