Search the practice set
126 questions, 454 terms and 400 topics in 20 areas.
60 results for “Integration Patterns”
Enterprise Integration Patterns
A catalogue of named, composable messaging patterns — router, translator, aggregator, splitter, filter, dead letter channel — that gives integration work a shared vocabulary.
Event-Driven Integration
Systems integrating by publishing and consuming events rather than by calling each other's APIs.
API Gateway
A single entry point in front of a set of services that handles authentication, rate limiting, routing and protocol translation.
Anti-Corruption Layer
A translation layer that converts a legacy or external system's model into your own, so its concepts do not leak into your domain.
Architecture Style
A named, coarse-grained way of organising a whole system, as distinct from a pattern that solves one recurring problem inside it.
Backend for Frontend
A separate, narrow backend per client experience, which aggregates and reshapes downstream services for exactly that client's needs.
Backward Compatibility
The property that a new version of a producer continues to work with clients written against the old version.
CI/CD
Merging work continuously into a shared trunk with automated verification, and keeping every commit in a state that could be released.
CQRS
Separating the model used to change state from the model used to read it, so each can be optimised independently.
Cell-Based Architecture
Partitioning a service into complete, independent copies of itself, each serving a subset of customers, so a failure is bounded to one cell.
Change Data Capture
Publishing a stream of a database's row-level changes by reading its replication log, without modifying the application that owns it.
Competing Consumers
Multiple identical consumers reading from one queue, so throughput scales with consumer count and work is distributed automatically.
Contract Testing
Verifying that a provider satisfies the expectations each of its consumers actually relies on, without running all the services together.
Dead Letter Queue
A separate queue that receives messages which could not be processed after a set number of attempts, so they neither block the consumer nor disappear.
Event Sourcing
Storing the full sequence of state-changing events as the system of record, and deriving current state by replaying them.
Event-Driven Architecture
A style in which components communicate by emitting and reacting to facts about what happened, rather than by calling each other.
GraphQL
A query language and runtime where the client specifies exactly which fields it needs, against a typed schema, usually via a single endpoint.
Hexagonal Architecture
Putting the domain at the centre and letting everything external — UI, database, queues — attach through ports implemented by replaceable adapters.
Idempotency Key
A client-generated unique value sent with a request so the server can recognise a retry and return the original result instead of acting twice.
Layered Architecture
Organising code into horizontal layers — presentation, application, domain, data — where each layer may only call the one beneath it.
LinkedIn and the Origin of Kafka
Kafka was built to replace point-to-point data integration between many systems with a single durable log that any system could publish to and any number could read.
Run a threat model on a new payment integration: our service calls a third-party payment provider and receives webhooks. Where are the interesting threats?
Draw the boundaries first Three trust boundaries, and nearly every interesting threat lives on one of them: 1. User → our service (untrusted input, authenticate
You must choose a data store this week. The product team cannot tell you the expected query patterns or the growth rate. What do you do?
What the interviewer is testing How you behave when the information you would like does not exist — which is the normal condition, not the exception. Both "refu
A downstream team needs to react to order changes. The order service can publish events, or they can consume CDC from its database. Which, and why?
The recommendation: published events, with CDC as the mechanism if needed The distinction that matters is what the consumer becomes coupled to . CDC consumed di
A service writes to its database and then publishes an event to Kafka. Sometimes consumers see an event for a record that does not exist, and sometimes a record exists with no event. Why, and how do you fix it?
What the interviewer is testing Recognition of the dual write problem — one of the most common defects in event driven systems and one that testing rarely catch
An order service must notify inventory, billing, shipping and analytics when an order is placed. Synchronous calls or events? Justify your choice per consumer.
What the interviewer is testing Whether you apply the decision per interaction rather than adopting one style globally. The framing that matters Synchronous cal
Design a URL shortener handling 100 million new links per month and 10 billion redirects. Where is the real difficulty?
What the interviewer is testing The classic warm up. What is being assessed is not whether you can shorten a URL — it is whether you do capacity arithmetic befo
Integration Patterns
Routers, translators, splitters, aggregators and dead letter channels.
Legacy Integration Patterns
Anti-corruption layers, adapters and CDC against systems that cannot change.
API & Integration
General material on integrating systems through contracts.
Architecture Patterns
General material on architectural patterns and their trade-offs.
Coexistence Patterns
Running old and new together for years without corrupting either.
Design Patterns
Reusable solutions at code level, and when they become ceremony.
Enterprise Integration
Estate-wide integration strategy, standards and shared infrastructure.
Event-Driven Integration
Publishing facts rather than commands, and versioning event schemas.
Legacy Integration
Reaching systems that cannot change, without importing their model.
Partner & B2B Integration
External contracts, onboarding, sandboxes and long deprecation windows.
Sharding Patterns
Directory versus embedded keys, logical shards and rebalancing.
API Documentation
OpenAPI as a machine-checked contract rather than as prose.
API Error Handling
Error shapes, retryability signals and machine-readable causes.
API Gateway
A single entry point for policy, routing and protocol translation.
API Versioning
URL, header and account-pinned versioning, and who carries the burden.
APIs as Products
Ownership, lifecycle, deprecation policy and developer experience.
Anti-Corruption Layer
Translating a foreign model at the boundary so it does not leak in.
Architecture Styles
System-level organising shapes, and how they differ from problem-level patterns.
Backend for Frontend
A narrow backend per client experience, owned by that client's team.
Backward Compatibility
Which changes are safe, and how to make breakage a build failure.
CI/CD
Continuous integration and delivery, and the architecture that caps them.
CQRS
Separate models for writing and reading, each optimised for its job.
Cell-Based Architecture
Complete isolated copies each serving a subset of customers.
Cloud Storage
Object, block and file storage, and the access patterns each suits.
Competing Consumers
Scaling throughput with instances, at the cost of ordering.
Contract Testing
Verifying what consumers actually rely on, without a shared environment.
Event Sourcing
The event log as the system of record, with state as a projection.
Event-Driven Architecture
Publishing facts, and trading comprehensibility for decoupling.
GraphQL
Client-specified queries, N+1 resolution and query-cost control.
Idempotency Keys
Client-generated keys stored atomically with the operation they guard.
Layered Architecture
The default shape, its clarity, and where a technical partition fails.