Integration Patterns and API Design Questions

Focuses on integration concepts, data flow, and API design as the foundation for connecting systems and services. Coverage includes data integration techniques such as ETL and ELT, change data capture, data warehousing, synchronization and eventual consistency challenges, latency and throughput considerations, middleware and messaging solutions, and common integration patterns used in marketing and enterprise stacks. For APIs, topics include what APIs are and why they matter for developer products, REST versus GraphQL trade offs and use cases, HTTP methods and semantics, authentication and authorization patterns, rate limiting and throttling, versioning strategies, idempotency and error handling, documentation and developer experience, monitoring and service level considerations, and how API choices affect product and business decisions.

HardTechnical

24 practiced

Design SLAs and SLOs for a multi-tenant developer platform offering API access to both small startups and large enterprises. Explain how you would tier SLO targets, enforce SLAs technically (rate limits, QoS), translate SLO breaches into contractual consequences, and monitor tenant-specific performance without exposing other tenants' data.

Sample Answer

**Context & goals**I’d design SLAs/SLOs that balance reliability for enterprises with cost-sensitive tiers for startups, while preserving tenant isolation and measurable enforcement.

**SLO tiers (examples)**- Enterprise Platinum: 99.99% availability, 50 ms P95 latency, guaranteed burst QPS, 0.01% error rate.- Business: 99.9% availability, 150 ms P95, default burst, 0.1% error rate.- Startup / Free: 99.5% availability, 300 ms P95, best-effort throughput, 1% error rate.

Tiering rationale: higher SLAs map to business impact, premium pricing, and stronger isolation provisions (dedicated capacity, SLB priority).

**Technical enforcement**- Rate limiting: per-tenant token bucket with dynamic quotas; separate global and per-tenant policies enforced at edge/API gateway.- QoS: request prioritization via weighted queues, circuit breakers, and admission control to protect higher-tier traffic.- Resource isolation: hybrid model — shared infra with cgroups/namespace limits for small tiers; soft/hard reservations or dedicated pools for Platinum.- Throttling/Backpressure: graceful 429 responses plus Retry-After headers and client SDK support.

**Contractual translation**- Define SLA credits: proportional service credits for downtime beyond SLO windows (e.g., 5% monthly credit for each 0.1% below target, capped).- Remediation paths: priority incident handling, root-cause analysis commitments, and termination clauses for repeated breaches.- Exclusions & measurement windows explicitly stated (maintenance, DDoS mitigations, customer-caused faults).

**Monitoring & tenant-specific observability**- Per-tenant telemetry pipeline: ingest metrics (latency, error, throughput) tagged by tenant ID into multi-tenant metrics store with strict RBAC.- Privacy: aggregate and anonymize cross-tenant dashboards; tenant-specific dashboards accessible only to that tenant and internal SRE/Support with audit logs.- Alerting: per-tenant SLO burn-rate alerts, automated paging for high-tier tenants.- Verification: independent monthly SLO reports and API for customers to retrieve their SLA metrics.

**Trade-offs & governance**- Cost vs. isolation: dedicated pools increase cost but reduce noisy-neighbor risk for premium tiers.- Complexity: implement incrementally—start with gateway rate limits and metrics, then add resource reservation.- Cross-functional rollout: align legal, sales, engineering, SRE for measuring, billing, and incident response playbooks.

This approach ties technical controls to commercial guarantees, protects high-value customers, and provides transparent, auditable measurement without exposing other tenants’ data.

MediumTechnical

23 practiced

You are defining the feature set of an API gateway for an integration platform MVP. Prioritize features and justify your ordering (e.g., authentication, rate-limiting, request transformation, caching, observability, service discovery, policy management). Explain the short-term and long-term trade-offs of your prioritization.

EasyTechnical

26 practiced

Explain the core REST principles and HTTP method semantics a TPM must know when specifying APIs: include the meaning of GET/POST/PUT/PATCH/DELETE, safe vs unsafe, idempotent vs non-idempotent, and typical status-code choices for success and common errors. Provide examples of when to use PUT vs PATCH.

Sample Answer

**Core REST principles (TPM lens)**

- Representational: resources identified by URIs; API returns representations (JSON, XML).- Stateless: each request contains auth/state; servers don’t keep client session state.- Uniform interface: standard methods and status codes for predictable developer experience.- Layered & cacheable: enable intermediaries and caching for scalability and performance.

**HTTP method semantics**

- GET — read-only, safe (no state change), idempotent, cacheable. Use to fetch resources.- POST — create or trigger processing, unsafe, non-idempotent (usually). Use to create with server-assigned ID or submit actions.- PUT — replace or create a resource at a known URI, unsafe, idempotent (repeating yields same result).- PATCH — partial update of resource, unsafe, typically non-idempotent unless designed idempotent; used for modifying fields.- DELETE — remove resource, unsafe, idempotent (deleting multiple times same result).

**Safe vs Unsafe / Idempotent vs Non-idempotent**

- Safe: does not alter server state (GET, HEAD). Good for caching and prefetch.- Idempotent: same effect when applied multiple times (GET, PUT, DELETE, HEAD, OPTIONS). POST and PATCH typically non-idempotent unless explicitly designed.

**Typical status codes**

- Success: 200 OK (read/update), 201 Created (resource created, include Location), 204 No Content (success with no body).- Client errors: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict (e.g., version conflict), 422 Unprocessable Entity (validation).- Server errors: 500 Internal Server Error, 503 Service Unavailable.

**PUT vs PATCH — when to use**

- Use PUT when the client can send the full resource representation and you want replace semantics. Example: PUT /users/123 with full user JSON ensures the resource equals payload; repeated PUTs are safe/idempotent.- Use PATCH for small, partial updates to avoid sending entire object or to support JSON Patch/JSON Merge Patch. Example: PATCH /users/123 with { "displayName": "Alex" } to change one field.

As a TPM I specify these in API docs, define idempotency expectations, recommend status-code mappings, and include migration/versioning guidance to ensure predictable DX.

EasyTechnical

31 practiced

Compare REST and GraphQL for a developer platform product. For each approach, describe typical use cases, developer experience implications, caching and observability challenges, API governance concerns, and business/product trade-offs that would influence your decision.

Sample Answer

**Overview (TPM perspective)** As a TPM I weigh developer velocity, maintainability, and business metrics when choosing REST vs GraphQL for a developer platform.

**REST — Typical use cases**- Public, resource-oriented APIs (CRUD services, simple integrations, webhooks).- Clear versioning boundaries for enterprise consumers.

**REST — Developer experience**- Predictable endpoints and HTTP semantics; easy to document (OpenAPI).- Can be verbose (over/under-fetching) but simple for SDK generation.

**REST — Caching & observability**- Strong HTTP caching (ETags, Cache-Control). CDN friendly.- Observability via request logs, status codes, and endpoint-level metrics.

**REST — Governance**- Straightforward contract/versioning policies; easier to enforce rate limits per endpoint.- Clear backward-compatibility rules.

**REST — Business trade-offs**- Faster to implement and scale via CDNs; may increase client work and data transfer costs.

---

**GraphQL — Typical use cases**- Complex, federated data needs (dashboards, mobile apps needing varied shapes).- Single endpoint aggregating multiple services.

**GraphQL — Developer experience**- Excellent for flexible, iterative front-end development; strong introspection and autogenerated docs.- Higher learning curve; needs client query management.

**GraphQL — Caching & observability**- Harder to cache at HTTP layer; requires query-level or persisted queries, caching per field/resolver, or CDN strategies (Apollo, persisted queries).- Observability needs traceable resolver-level metrics and query complexity analysis to detect hot/resolver abuse.

**GraphQL — Governance**- Schema-first governance essential (breaking-change CI checks, field deprecation lanes).- Need query cost limiting, auth at field level, and careful federation ownership.

**GraphQL — Business trade-offs**- Improves developer velocity and product polish but increases backend complexity and operational cost. Better for differentiated UX; heavier lift for security and performance controls.

**Decision guidance**- Choose REST when you need predictable, cacheable, low-op overhead APIs and enterprise contracts. Choose GraphQL when client flexibility, rapid frontend iteration, and aggregated data access drive product value — but budget for governance, tooling, and ops.

EasyTechnical

47 practiced

List common API versioning strategies (URI versioning, header/version negotiation, semantic versioning, hypermedia) and explain the pros and cons of each. As a TPM, recommend which strategy to standardize on for a public API and justify how you would enforce and document that choice.

Unlock Full Question Bank

Get access to hundreds of Integration Patterns and API Design interview questions and detailed answers.

Join thousands of developers preparing for their dream job.