API Composition vs Database Joins: How Do They Differ?
Understand how API composition differs from a database join, why microservices need it, and its latency trade-offs.
Expected Interview Answer
A database join combines rows from multiple tables in a single database engine using one SQL statement, while API composition assembles a result by calling multiple separate services' APIs and merging their responses in application code, because in a microservices system the underlying data lives in separate databases that cannot be joined directly.
A join is efficient because the database engine has direct access to all the rows involved and can use indexes to match them in one optimized query plan. API composition instead requires an orchestrating service (an API composer) to call each downstream service, wait for each response, and stitch the results together — for example, fetching an order from the Orders service, then calling the Users service for the customer's name. This is slower and more complex, since it introduces network latency per call, partial-failure handling, and potential N+1 fan-out if not batched, but it is necessary once data-per-service means no single database holds all the tables involved.
- Database joins: single fast query, no network hops, ACID-consistent read
- API composition: works across independently-owned service databases
- API composition preserves service autonomy and deployment independence
- Composition can be optimized with parallel calls and caching
AI Mentor Explanation
A database join is like a scorer with one master book containing both batting and bowling stats, instantly cross-referencing a player's batting average against their economy rate on the same page. API composition is like having to call the batting statistician and the bowling statistician separately, wait for each to reply, then manually combine both answers into one report yourself. The join is a single fast lookup inside one book; composition is coordinating across two separate, disconnected record-keepers.
API Composition Assembling Data From Two Services
API Composer
- calls Orders service
- calls Users service
- merges results
Orders Service
- order_id
- user_id
- total
Users Service
- user_id
- name
Step-by-Step Explanation
Step 1
Identify the cross-service query need
Recognize the required data spans two or more independently-owned service databases.
Step 2
Call each service's API
The composer service issues requests to each downstream service for its portion of the data.
Step 3
Wait for and validate responses
Handle latency and partial failures if one downstream service is slow or unavailable.
Step 4
Merge results in application code
Combine the separate responses into one unified result to return to the caller.
What Interviewer Expects
- Clear distinction between a single-engine SQL join and multi-service orchestration
- Awareness of latency, partial-failure, and N+1 fan-out risks in composition
- Understanding of why composition becomes necessary under database-per-service
- Ability to suggest mitigations like parallel calls, caching, or CQRS read models
Common Mistakes
- Treating API composition as a drop-in replacement with identical performance to a join
- Ignoring partial-failure handling when one downstream call fails
- Not mentioning that composition is a consequence of the database-per-service pattern
- Assuming composition always requires sequential rather than parallel calls
Best Answer (HR Friendly)
“A database join lets one query pull matching data from multiple tables inside a single database instantly. API composition is what you do instead when that data lives in separate microservices' databases: you call each service, wait for the answers, and stitch the results together in code. It works, but it's slower and needs careful handling of failures and latency compared to a plain join.”
Code Example
-- Database join: works only when both tables share one database
SELECT o.order_id, o.total, u.name, u.email
FROM Orders o
JOIN Users u ON u.id = o.user_id
WHERE o.order_id = 501;
-- API composition: required when Orders and Users are separate services
-- Step 1: query the Orders service's own database
SELECT order_id, user_id, total FROM Orders WHERE order_id = 501;
-- Step 2 (application code, not SQL):
-- call GET /users/{user_id} on the Users service
-- then merge the returned name/email with the order row aboveFollow-up Questions
- How would you avoid N+1 fan-out when composing data from multiple services?
- How does CQRS with a materialized read model compare to API composition?
- How do you handle a partial failure when one downstream service in a composition is down?
- When is it acceptable to denormalize data to avoid composition entirely?
MCQ Practice
1. Why is API composition needed instead of a SQL join in many microservices systems?
Under database-per-service, no single database holds all the needed tables, so a SQL join is not possible across services.
2. What is a key risk of naive API composition across several downstream calls?
Each composed call adds network latency, and calling a downstream service once per item can create an N+1-style explosion of requests.
3. Compared to a join, what does API composition trade away?
A join is one atomic, low-latency operation inside one engine; composition trades that for multiple network calls merged afterward.
Flash Cards
What is a database join? — A single SQL operation combining rows from multiple tables within one database engine.
What is API composition? — Calling multiple services' APIs separately and merging their responses in application code.
Why use API composition over a join? — Because the needed data lives in separate databases owned by different microservices.
Main downside of API composition? — Added network latency, partial-failure handling, and possible N+1 call fan-out.