All jobs / Solutions / cloud architect
Integration interview questions
Integration questions a Solutions / cloud architect can be asked, from first job to senior. Open one to see the strongest answer and why it works.
Checkout calls the email service directly; when the mail provider is slow, orders time out.
Why put a queue between the order service and the email sender?
The strongest answer: So the order is accepted even if email is slow or down, and the sender can work at its own pace with retries — email is not on the order’s critical path
Why it works: Exactly. Decoupling availability and pace. The order does not wait for a mail server.
- Decouple availability: order succeeds without email.
- Consumer works at its own pace.
- Retries live in the queue.
- Only where an immediate answer is not needed.
A payment provider sends you webhooks when a payment settles. What must your receiving endpoint do?
The strongest answer: Verify the signature, acknowledge quickly and process asynchronously, cope with the same event arriving twice, and treat the payload as a notification to verify against the provider rather than as the truth
Why it works: Exactly — authenticate, acknowledge, process later, dedupe, verify.
- Verify, acknowledge, process, dedupe.
- Check the signature first.
- Respond fast; work asynchronously.
- Idempotent on duplicates.
Orders currently succeed or fail based on whether the payment provider answers within thirty seconds.
The payments team wants the order service to call them synchronously for every order. What do you weigh?
The strongest answer: Whether the order truly needs the payment answer before it can proceed; if yes, keep it synchronous with timeouts and a fallback state, if not, make it an event and reconcile
Why it works: Exactly. The business question decides the integration style, and either way the failure behaviour is designed.
- Does this step need the answer now?
- Sync: timeouts and a fallback state.
- Async: events and reconciliation.
- Own your availability either way.
How do you change the shape of an event that three other teams already consume?
The strongest answer: Add optional fields and never repurpose existing ones; for a breaking change publish a new version alongside the old until consumers have moved, and record the contract in a schema registry or shared repo
Why it works: Exactly. Additive by default, versioned when breaking, contract written down.
- Additive changes only, by default.
- Breaking change: new version side by side.
- Write the contract down.
- Consumers move on their timeline.
gRPC or REST for calls between your services?
The strongest answer: gRPC for internal service-to-service calls where typed contracts, streaming and efficiency matter; REST with JSON where browsers, third parties, caching or broad tooling matter — browsers need a proxy to speak gRPC
Why it works: Right — the audience of the API decides: internal typed clients versus public and browser consumers.
- Audience decides the protocol.
- gRPC: internal, typed, streaming.
- REST: public, browser, cacheable.
- Browsers need a proxy for gRPC.
How do you pick between a queue and a streaming log for an integration?
The strongest answer: Ask whether messages are tasks to be consumed once or a history several consumers replay; ordering, retention and replay needs decide it more than throughput does
Why it works: Exactly. Consume-once tasks versus replayable history; ordering and retention are the real axis.
- Task consumed once, or history replayed?
- Ordering and retention decide.
- Throughput rarely does.
- Neither is universal.
What is a dead-letter queue for, and what has to exist alongside it?
The strongest answer: A place for messages that keep failing so they stop blocking the queue; alongside it you need alerting, a way to inspect and replay them, and an owner
Why it works: Exactly. Isolate the poison, keep the queue moving, and make sure a human sees and can replay.
- Isolate messages that keep failing.
- Alert on arrivals.
- Inspect and replay tooling.
- A named owner.
What is different about integrating a third-party API compared with one of your own services?
The strongest answer: You control neither its changes, uptime, rate limits nor its data model: wrap it in an adapter that speaks your model, pin the version, test against its sandbox, respect the quotas, watch its status, and keep an exit plan
Why it works: Exactly — the adapter isolates their world from yours, and the rest is respecting what you do not control.
- You do not control it — isolate it.
- Adapter speaks your model.
- Pin versions, use the sandbox.
- Quotas, status page, exit plan.
How do you publish an event and update the database so that neither happens without the other?
The strongest answer: Write the event to an outbox table in the same transaction as the state change, then have a relay publish it and mark it sent — the consumer handles duplicates
Why it works: Exactly. One local transaction, a relay, idempotent consumers.
- Outbox row in the same transaction.
- A relay publishes and marks sent.
- Consumers tolerate duplicates.
- No 2PC across broker and database.
A vendor promises “exactly-once delivery”. How do you design around that claim?
The strongest answer: Treat delivery as at-least-once and make every consumer idempotent — dedupe by message id or natural key — so exactly-once becomes an outcome your design guarantees rather than a promise you rely on
Why it works: Exactly. At-least-once transport plus idempotent processing is exactly-once effect.
- Assume at-least-once.
- Idempotent consumers.
- Dedupe by id or natural key.
- Exactly-once is an effect you build.
Design outbound webhooks that notify customers’ systems about events in your platform.
The strongest answer: Sign each delivery, send from a queue with retries and backoff, include an event id so receivers can dedupe, document that order is not guaranteed, park endpoints that keep failing, and show customers their delivery log
Why it works: Exactly — a webhook system is a small delivery platform: durable, signed, idempotent and observable.
- Durable, signed, idempotent, observable.
- Queue, retries, backoff.
- Event id for dedupe.
- Delivery log the customer can see.
The warehouse is fed by a nightly full export of the orders database and it now takes nine hours. What are the options?
The strongest answer: Move to incremental loads using a change watermark, or capture changes from the database log so the warehouse follows in near real time; load raw and transform in the warehouse, and stop scanning the whole table
Why it works: Right — the fix is to move only what changed, whether by watermark or by change data capture.
- Move what changed, not everything.
- Watermark for incremental loads.
- CDC from the log for near real time.
- Load raw, transform in the warehouse.
The core banking system exposes only SOAP web services. How does a modern platform integrate with it?
The strongest answer: Through one adapter service that owns the SOAP client generated from the contract, translates to the platform’s model, absorbs the system’s quirks and faults, and shields everything else — the one place to change when the core changes
Why it works: Exactly — an anti-corruption layer keeps the legacy model and protocol out of the platform.
- One adapter owns the legacy.
- Generated client behind your model.
- Absorb quirks and faults there.
- One place to change later.
Forty systems integrate point-to-point and every change breaks something nobody knew depended on it. What do you propose?
The strongest answer: Map the flows, then move the high-fan-out ones onto an event backbone with owned, versioned contracts and the request-response ones behind managed APIs, with a registry of who consumes what — not a central bus that holds the business logic
Why it works: Right — contracts, ownership and discoverability fix the spaghetti; a central logic hub just relocates it.
- Contracts, ownership, discoverability.
- Events for fan-out, APIs for request-response.
- Registry of consumers.
- No business logic in the bus.