5 exercises — practice the language for integration patterns, ESB, API gateways, event brokers, and hub-and-spoke vs point-to-point discussions.
0 / 18 completed
1 / 18
Your architecture team is debating between two integration topologies.
A colleague says: "Point-to-point integrations worked when we had five systems. Now we have forty — we need a hub-and-spoke model."
What problem is the colleague describing?
The core problem with point-to-point integration is combinatorial explosion. With 5 systems: 10 connections. With 40 systems: 780 connections. Each is a custom pipeline to maintain, monitor, and modify when either system changes. A hub-and-spoke model (ESB, API gateway, or event broker as the hub) reduces this to n connections — each system connects once to the hub. The tradeoff: the hub becomes a single point of failure and a potential bottleneck.
2 / 18
An architect recommends using an API gateway as the integration layer.
Which statement best describes the role of an API gateway?
An API gateway sits at the north-south traffic boundary (external consumers → internal services) and centralises cross-cutting concerns: authentication/authorisation, rate limiting, SSL termination, request routing, protocol translation (REST↔gRPC), and logging. Examples: AWS API Gateway, Kong, Apigee, Azure API Management. Distinguish from a service mesh (east-west, internal service-to-service) and an ESB (broader orchestration, transformation, routing).
3 / 18
Complete the architecture decision from an integration review:
"For our order processing pipeline, we chose an _____ broker over synchronous REST calls — this decouples the order service from fulfilment and allows each to scale independently without blocking."
An event broker (Kafka, RabbitMQ, AWS SNS/SQS, Azure Service Bus) enables asynchronous, decoupled communication. Publishers emit events; subscribers consume them independently. The language "decouples... allows each to scale independently without blocking" is the canonical justification for choosing an event broker over synchronous REST. Note: "message broker" is also widely used and broadly acceptable — the distinction is that event brokers (like Kafka) retain event history, while traditional message brokers (like RabbitMQ) delete messages after delivery.
4 / 18
During a migration discussion, the team references an ESB (Enterprise Service Bus).
What is an ESB, and what is a common criticism of the pattern?
An ESB was the dominant enterprise integration pattern of the 2000s. It centralises routing, transformation, orchestration, and protocol translation. The classic criticism (popularised by microservices advocates) is that ESBs become "smart pipes" that accumulate business logic — violating the principle that services should be the source of truth for their own behaviour. Martin Fowler's "dumb pipes, smart endpoints" is the counter-pattern. That said, ESBs remain appropriate in many enterprise contexts where centralised governance and transformation are required.
5 / 18
Which sentence correctly uses integration architecture vocabulary in a design review?
Option B uses vocabulary correctly and quantifiably: point-to-point mesh (the problem), event broker (the solution), reduction in connections (the measured benefit), and event replay (an additional capability). This is the language of a credible integration architecture decision. Option A is a contradiction — ESB and point-to-point are alternative patterns. Option D confuses ESB (integration middleware) with service mesh (infrastructure layer for east-west traffic).
6 / 18
// Slack message from a developer during code review
You're reviewing a PR that uses a new Kafka topic for event streaming. A senior developer comments: 'This approach seems tightly coupled to the downstream services; we'll likely need to change the consumer logic every time we update the event schema.' What architectural concern is this comment primarily highlighting regarding the integration architecture?
This comment accurately identifies the core issue: tight coupling. The developer is concerned that changes to the event schema in Kafka will necessitate modifications across all consuming services. Loose coupling—a cornerstone of good integration architecture—aims to minimize these ripple effects by promoting independent evolution of systems. Option A misinterprets the situation as a technical infrastructure problem, while option C suggests an inappropriate technology choice and option D focuses on code quality rather than architectural design.
7 / 18
PR Description:
"Implemented a new Kafka topic, `order_events`, to stream order updates. Consumers include the fulfillment service and the reporting dashboard. The schema is versioned and managed by our team."
The comment highlights a key concern regarding integration architecture: tight coupling. While asynchronous messaging (Kafka) is beneficial, the description reveals that changes to the `order_events` schema require updates in *all* consumer services. This creates a dependency and increases operational complexity – a common criticism of poorly designed event-driven architectures. Options A and B misinterpret the implications of using Kafka; option D is overly optimistic about throughput gains without considering the architectural challenges.
8 / 18
// Slack message from a developer during code review
You're reviewing a PR that uses a new Kafka topic for event streaming. A senior developer comments: 'This approach seems tightly coupled to the downstream services; we'll likely need to change the consumer logic every time we update the event schema.' What architectural concern is this comment primarily highlighting regarding the integration architecture?
This comment accurately identifies the core issue: tight coupling. The developer is concerned that changes to the event schema in Kafka will necessitate modifications across all consuming services. Loose coupling—a cornerstone of good integration architecture—aims to minimize these ripple effects by promoting independent evolution of systems. Option A misinterprets the situation as a technical infrastructure problem, while option C suggests an inappropriate technology choice and option D focuses on code quality rather than architectural design.
9 / 18
PR Description:
"Implemented a new Kafka topic, `order_events`, to stream order updates. Consumers include the fulfillment service and the reporting dashboard. The schema is versioned and managed by our team."
The comment highlights a key concern regarding integration architecture: tight coupling. While asynchronous messaging (Kafka) is beneficial, the description reveals that changes to the `order_events` schema require updates in *all* consumer services. This creates a dependency and increases operational complexity – a common criticism of poorly designed event-driven architectures. Options A and B misinterpret the implications of using Kafka; option D is overly optimistic about throughput gains without considering the architectural challenges.
10 / 18
// Slack message from a developer during code review
You're reviewing a PR that uses a new Kafka topic for event streaming. A senior developer comments: 'This approach seems tightly coupled to the downstream services; we'll likely need to change the consumer logic every time we update the event schema.' What architectural concern is this comment primarily highlighting regarding the integration architecture?
This comment accurately identifies the core issue: tight coupling. The developer is concerned that changes to the event schema in Kafka will necessitate modifications across all consuming services. Loose coupling—a cornerstone of good integration architecture—aims to minimize these ripple effects by promoting independent evolution of systems. Option A misinterprets the situation as a technical infrastructure problem, while option C suggests an inappropriate technology choice and option D focuses on code quality rather than architectural design.
11 / 18
PR Description:
"Implemented a new Kafka topic, `order_events`, to stream order updates. Consumers include the fulfillment service and the reporting dashboard. The schema is versioned and managed by our team."
The comment highlights a key concern regarding integration architecture: tight coupling. While asynchronous messaging (Kafka) is beneficial, the description reveals that changes to the `order_events` schema require updates in *all* consumer services. This creates a dependency and increases operational complexity – a common criticism of poorly designed event-driven architectures. Options A and B misinterpret the implications of using Kafka; option D is overly optimistic about throughput gains without considering the architectural challenges.
12 / 18
// Slack message from a developer during code review
You're reviewing a PR that uses a new Kafka topic for event streaming. A senior developer comments: 'This approach seems tightly coupled to the downstream services; we'll likely need to change the consumer logic every time we update the event schema.' What architectural concern is this comment primarily highlighting regarding the integration architecture?
This comment accurately identifies the core issue: tight coupling. The developer is concerned that changes to the event schema in Kafka will necessitate modifications across all consuming services. Loose coupling—a cornerstone of good integration architecture—aims to minimize these ripple effects by promoting independent evolution of systems. Option A misinterprets the situation as a technical infrastructure problem, while option C suggests an inappropriate technology choice and option D focuses on code quality rather than architectural design.
13 / 18
PR Description:
"Implemented a new Kafka topic, `order_events`, to stream order updates. Consumers include the fulfillment service and the reporting dashboard. The schema is versioned and managed by our team."
The comment highlights a key concern regarding integration architecture: tight coupling. While asynchronous messaging (Kafka) is beneficial, the description reveals that changes to the `order_events` schema require updates in *all* consumer services. This creates a dependency and increases operational complexity – a common criticism of poorly designed event-driven architectures. Options A and B misinterpret the implications of using Kafka; option D is overly optimistic about throughput gains without considering the architectural challenges.
14 / 18
During a sprint planning meeting, the team discusses integrating with a new third-party API. Sarah says, 'We need to ensure loose coupling and avoid tight integration – we don't want any dependencies between our services.' Which architectural principle is Sarah referring to?
Loose coupling describes the ability of components to operate independently with minimal dependencies. This contrasts with *tight coupling*, where changes in one component require changes in others. Sarah is advocating for a design that promotes flexibility and resilience.
15 / 18
You're reviewing a Slack message from the DevOps team regarding an integration issue: 'The order processing service is experiencing high latency due to excessive calls to the external payment gateway.' What does this likely indicate about the integration architecture?
An overloaded integration point suggests that the order processing service is making too many requests to the payment gateway, potentially causing bottlenecks and latency. This indicates a need for redesigning the integration pattern—perhaps using asynchronous messaging or caching.
16 / 18
A developer is writing a PR description for a new microservice that sends event notifications to other services. They include the following: 'The service publishes events on a Kafka topic using a schema defined in Avro.' What architectural concept does this primarily represent?
Event-driven architecture is characterized by services reacting to events published by other services. Kafka topics and Avro schemas are commonly used in this pattern for reliable and scalable event streaming. It's important to distinguish from message queuing (which is a *part* of the system), or synchronous API calls.
17 / 18
During a standup meeting, Mark mentions: 'We're using an Enterprise Service Bus (ESB) to connect our legacy systems.' What is the *primary* purpose of an ESB in this context?
The primary purpose of an ESB is to act as a middleware layer, facilitating communication between disparate applications. This typically involves message transformation (converting data formats), routing messages to the correct destinations, and potentially handling protocol conversions – *not* strict validation or automated scaling.
18 / 18
You're reviewing a code review comment: 'This integration should be designed to minimize the impact of changes in one service on others. We need to avoid cascading failures.' Which architectural principle is being emphasized?
Resilience focuses on the ability of a system to withstand faults and continue operating correctly. Minimizing cascading failures directly relates to this principle—a resilient design avoids single points of failure and prevents issues in one component from spreading throughout the entire integration.
What does the "Integration Architecture Vocabulary — Enterprise Architecture English Exercise" exercise cover?
Practice English for integration architecture: ESB, API gateway, event broker, hub-and-spoke vs point-to-point, and integration pattern discussion language. 5 exercises.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Integration Architecture Vocabulary — Enterprise Architecture English Exercise"?
This exercise has 18 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Enterprise Architecture Language exercises?
Browse the full Enterprise Architecture Language hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.