Learn vocabulary for API gateway roles, BFF pattern, rate limiting, gateway aggregation, and sidecar pattern in microservices.
0 / 10 completed
1 / 10
What is the primary role of an API gateway in a microservices architecture?
An API gateway is the front door to your microservices system. Clients call the gateway; the gateway routes requests to the appropriate downstream services. It centralizes cross-cutting concerns: authentication/authorization, rate limiting, SSL termination, request/response transformation, logging, and tracing — so each service doesn't re-implement them.
2 / 10
What is the Backend for Frontend (BFF) pattern in API gateway vocabulary?
BFF (Sam Newman): instead of one general-purpose API gateway, create one gateway per frontend type. The mobile BFF returns compact payloads optimized for mobile bandwidth; the web BFF returns richer data. Each BFF is owned by the team building that frontend. This avoids the 'general-purpose gateway' anti-pattern where one gateway tries to serve conflicting client needs.
3 / 10
What is 'rate limiting at the gateway' in microservices vocabulary?
Rate limiting at the gateway enforces request quotas: e.g., 1000 requests per minute per API key. When the limit is exceeded, the gateway returns 429 Too Many Requests without forwarding to downstream services. This protects backend services from overload, prevents abuse, and enables fair usage policies — all in one centralized place.
4 / 10
What is 'gateway aggregation' in microservices vocabulary?
Gateway aggregation (also called API composition): the client makes one request to the gateway; the gateway calls Service A, Service B, and Service C in parallel, combines their responses, and returns a single response. This reduces client complexity and network round trips — especially valuable for mobile clients with high latency or limited connections.
5 / 10
What distinguishes the sidecar pattern from an API gateway in microservices vocabulary?
Sidecar pattern (used in service meshes like Istio/Linkerd): a proxy container runs next to each service instance, intercepting all inbound and outbound traffic. It handles mTLS, retries, circuit breaking, and telemetry — transparently, without changing service code. An API gateway handles north-south traffic (client→system); sidecars handle east-west traffic (service→service).
6 / 10
Code Review Comment: 'I'm seeing a lot of requests hitting the UserProfile service directly. Shouldn't this be routed through the API Gateway for enhanced security and logging?' What does this comment primarily highlight regarding API gateway usage?
This comment is focusing on the core value proposition of an API gateway: acting as a centralized point for managing traffic to microservices. It's not about database optimization or latency (although gateways *can* influence those), but rather leveraging the gateway's built-in features like security policies and logging to protect the UserProfile service. The incorrect options represent tangential issues that aren't directly related to the gateway's role.
7 / 10
Slack Message: 'Hey team, just running a quick check on the new Order Service API Gateway configuration. We've implemented request validation and transformation to ensure all incoming data conforms to our schema before it reaches the backend. This is crucial for preventing bad data from corrupting our order processing system.' What aspect of the API gateway does this message primarily describe?
This Slack message is centered around the API Gateway's function as a gatekeeper for incoming requests. The core purpose highlighted here is request validation and transformation – tasks that are commonly handled by gateways to ensure data integrity before it reaches the backend services. Options A and B describe broader architectural concepts, while C is a potential *function* of the gateway but not its primary role in this specific scenario.
8 / 10
API Response: The API Gateway returns the following JSON response after receiving a request to retrieve user details:
{
"statusCode": 200,
"headers": {
"x-rate-limit-remaining": 5,
"x-request-id": "abc123xyz"
},
"data": {
"userId": 12345,
"userName": "John Doe"
}
What does the 'x-rate-limit-remaining' header indicate in this context?
The 'x-rate-limit-remaining' header is a standard indicator used in API gateways to manage rate limiting. It directly reflects the number of requests remaining within a defined time window for a particular endpoint. The other options represent different aspects of API responses or system monitoring – they are not related to rate limiting.
9 / 10
PR Description: 'Adding gateway configuration for request validation and transformation on the Product Service. This will ensure all incoming requests adhere to our predefined schema, preventing data corruption and improving overall system reliability.' What architectural pattern is this PR primarily implementing?
This PR description clearly aligns with the BFF (Backend for Frontend) pattern. The BFF is designed to create tailored APIs for specific clients or frontends by transforming and validating data before it reaches backend services – precisely what this configuration does. The other options represent different architectural patterns focused on resilience, service discovery, or network management.
10 / 10
Standup Update: 'We've been working on implementing a new API Gateway to centralize authentication and authorization across all our microservices. We're also exploring the use of gateway aggregation to reduce the number of calls made to backend services, improving performance.' What is 'gateway aggregation' in this context?
Gateway aggregation refers to combining multiple requests into a single request sent to the backend service. This reduces network overhead by minimizing the number of round trips between the gateway and the backend. The other options represent different aspects – security (encryption), scaling (auto-scaling), or simply deploying multiple gateways.
What will I practise in "API Gateway Patterns — Microservices Vocabulary"?
This module focuses on Microservices Language — real workplace phrasing you'll use on the job. It contains 10 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 10 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Microservices Language exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around microservices language — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Microservices Language exercises?
See the Microservices Language hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.