All jobs / Solutions / cloud architect
Application Architecture interview questions
Application Architecture questions a Solutions / cloud architect can be asked, from first job to senior. Open one to see the strongest answer and why it works.
A new product with a team of four: monolith or microservices to start?
The strongest answer: A well-structured monolith with clear module boundaries — services add network, deployment and data-consistency costs the team does not need yet
Why it works: Exactly. Modules now, services when a boundary earns the network hop. The structure is what keeps the option open.
- Start modular, not distributed.
- Services cost network, deploys and consistency.
- Boundaries follow the domain.
- Keep the split as a later option.
When would you choose a REST call over publishing an event, and when the reverse?
The strongest answer: REST when the caller needs the answer now and owns the decision; an event when several parties may care and the publisher should not know who they are
Why it works: Exactly. Who needs the answer and who should know about whom decides it.
- Need the answer now? Call.
- Many interested parties? Publish.
- Publisher should not know consumers.
- Neither is “always”.
What does designing an API “contract-first” mean, and why do teams do it?
The strongest answer: You write and review the interface specification before the implementation, so consumers can build against mocks in parallel and the contract is a deliberate design rather than whatever the code happened to expose
Why it works: Exactly — the contract is the product; code follows it and both sides work at once.
- The contract comes first.
- Spec, review, then code.
- Consumers build against mocks.
- Design the shape deliberately.
What does an API gateway do for you, and what should you resist putting in it?
The strongest answer: One entry point handling authentication, rate limits, routing and TLS; resist business logic — a gateway full of rules becomes a hidden monolith nobody owns
Why it works: Exactly. Cross-cutting concerns in, business rules out.
- One front door for cross-cutting concerns.
- Auth, throttling, routing, TLS.
- No business logic inside.
- Services still verify identity.
A client retries a “create payment” request after a timeout. How does the design stop a double charge?
The strongest answer: The client sends an idempotency key; the server stores the result under that key and returns the same response on a repeat, so retries are safe by design
Why it works: Exactly. Key on the request, result stored, replay returns the original. Retries become harmless.
- Client supplies an idempotency key.
- Server stores the result by key.
- Replay returns the same answer.
- Retries are a given; design for them.
How do you version a public API so you can change it without breaking customers?
The strongest answer: Make additive changes without a version bump, put breaking changes behind a new major version, run old and new in parallel with a published sunset date, and measure who still calls the old one
Why it works: Exactly. Additive quietly, breaking under a version, parallel run, measured deprecation.
- Additive changes need no version.
- Breaking changes get a new major.
- Run both; publish the sunset date.
- Measure remaining callers before removal.
Two services both need customer data. Who owns it, and how does the other get it?
The strongest answer: One service owns the write model and is the source of truth; the other reads through its API or keeps a local copy fed by events, accepting that the copy lags
Why it works: Exactly. One writer, one truth; others read or subscribe and accept the lag.
- One owner writes.
- Others read via API or events.
- Copies lag by design.
- No shared tables between services.
How do you keep a monolith modular enough that you could split it into services later?
The strongest answer: Modules with explicit public interfaces, each owning its own tables, no cross-module joins or shared entities, communication through interfaces or in-process events — with the rules enforced by build checks, not convention
Why it works: Right — a modular monolith is defined by data ownership and enforced dependencies, not by folders.
- Enforced modules, owned data.
- Explicit interfaces per module.
- No cross-module joins.
- Build checks enforce the rules.
The booking flow sometimes charges the card after the hotel step has already failed.
Booking a trip touches flights, hotel and payment services. How do you keep them consistent?
The strongest answer: A saga: each step commits locally and publishes; failures trigger compensating actions, and the booking has explicit intermediate states the user can see
Why it works: Exactly. Local commits, compensation, visible states. It is more work and it is the honest model.
- Saga: local commits plus compensation.
- Intermediate states are explicit.
- Avoid cross-service 2PC.
- Half-done must be visible and recoverable.
A fifteen-year-old billing system must be replaced while it keeps invoicing every month.
How do you replace a large legacy system without a big-bang cut-over?
The strongest answer: Put a facade in front, route one capability at a time to the new system while the old keeps serving the rest, and retire the old pieces as traffic moves — the strangler fig pattern
Why it works: Exactly. Facade, incremental routing, measured retirement. Every step is reversible.
- Facade in front of the legacy.
- Move one capability at a time.
- Retire as traffic moves.
- Every step reversible.
When does separating read and write models earn its complexity, and when does it not?
The strongest answer: When reads and writes have very different shapes, scale or consistency needs; not for a CRUD service where the same model serves both — the extra sync path is a permanent cost
Why it works: Exactly. Different shapes or scales justify the split; CRUD does not.
- Different read and write shapes justify it.
- CRUD does not.
- The sync path is a permanent cost.
- Separate decision from event sourcing.
A team proposes event sourcing for the whole platform. What do you check before agreeing?
The strongest answer: Whether the domain genuinely needs history and replay, how they will handle event versioning, snapshots, projections and deletion requests, and whether they have run one bounded context this way first
Why it works: Exactly. Need, versioning, projections, deletion, and a proven pilot before a platform-wide bet.
- Does the domain need replayable history?
- Versioning, snapshots, projections planned?
- Deletion requests handled?
- One bounded context first.
How do you decide where one service ends and another begins?
The strongest answer: Around a business capability with its own language and data that changes together; a boundary is right when the services rarely need each other’s data in the same transaction
Why it works: Exactly. Capability, language, data that changes together, and few cross-boundary transactions.
- Cut around business capabilities.
- Own language and data.
- Data that changes together stays together.
- Few cross-boundary transactions.
For a saga across several services — choreography through events, or an orchestrator?
The strongest answer: An orchestrator when the flow has many steps, branches or compensations and you need one place to see state and handle failure; choreography when there are few steps and loose coupling matters more than visibility
Why it works: Exactly — the choice follows flow complexity and how badly you need to see and control state.
- Complexity decides the style.
- Orchestrator: visibility, compensation.
- Choreography: few steps, loose coupling.
- Watch for hidden event coupling.
Forty services in three languages, each with its own retry and TLS handling.
The platform team wants a service mesh. How do you decide whether it is worth it?
The strongest answer: Count the concrete problems it solves — mutual TLS, retries, traffic shifting, uniform telemetry — against the operational weight and the alternative of libraries; adopt where the service count makes the library path unmanageable
Why it works: Exactly. Named problems, weighed against operational cost and the library alternative.
- List the problems it solves.
- Weigh operational weight.
- Compare with the library path.
- Gateway and mesh are different layers.
When is a serverless function the right choice, and when does it turn into a trap?
The strongest answer: Right for spiky, event-driven, short tasks where you want no capacity management; a trap for steady high-volume workloads, long-running jobs or chatty call chains where cold starts, limits and per-invocation cost bite
Why it works: Exactly. Spiky and short: yes. Steady, long or chatty: count the cost and the limits.
- Spiky, event-driven, short: good fit.
- Steady high volume: model the cost.
- Long jobs and chatty chains: beware.
- Not a way to skip learning.