Search the practice set
275 questions, 991 terms and 600 topics in 30 areas.
60 results for “API Shapes for UI”
Over-Fetching
Transferring fields the interface will not display, which costs bandwidth and parse time on exactly the devices least able to afford them.
API Deprecation Policy
The published commitment about how long a version is supported, how notice is given, and what consumers can expect — without which nothing is ever retired.
API Gateway
A single entry point in front of a set of services that handles authentication, rate limiting, routing and protocol translation.
Semantic Diffing of API Schemas
Comparing the published contract between builds and failing the build on a breaking change, so compatibility is mechanical rather than remembered.
Server State Versus UI State
The distinction between data owned elsewhere and cached locally, and state that exists only in this session — conflating them causes most client state bugs.
Stripe's API Versioning
Stripe pins each account to the API version current when it integrated and transforms requests and responses between versions internally, so integrations never break and the core …
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.
Build Graph Scoping
Determining which packages a change actually affects, so a monorepo builds and tests a subset rather than everything on every commit.
Client-Specific Aggregation
A dedicated backend per client type that shapes and combines downstream data for that client's needs, owned by the client team.
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.
Deprecation Window
The stated period between announcing that an internal interface will be removed and removing it, with the removal actually happening at the end.
Developer Portal
The self-service surface where consumers discover APIs, read documentation, obtain credentials and test calls — the main determinant of adoption.
Diagram Notation Consistency
Using shapes, colours, line styles and arrow directions to mean the same thing across every diagram, and stating what they mean on the diagram itself.
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.
Gateway Aggregation
Combining several backend calls into one client-facing response at the gateway, reducing client round trips at the cost of coupling the gateway to backend structure.
Gateway Offloading
Moving cross-cutting concerns — TLS termination, authentication, rate limiting, compression, logging — from every service into the gateway.
Gateway Timeout Chain
The sequence of timeouts from client through load balancer, gateway and service, which must decrease inward or produce confusing failures.
A core mainframe system with no API supports nightly batch file exchange only. The business needs near-real-time order status. Design the integration.
Establish the real constraint "No API" usually means no API the mainframe team will build on your timeline . Find out what exists: message queue interfaces, dat
A global SaaS product has a 200 ms p95 API budget. Users in Sydney see 900 ms against a single US-East deployment. The application team says the service responds in 40 ms. Who is right and what do you do?
Both are right, and that is the point The service does respond in 40 ms. The other 860 ms is network — and no amount of application profiling will show it, whic
A new platform must serve a public partner API, three internal front-ends with different data needs, and high-volume service-to-service traffic. Choose the API styles and defend the choice.
Resist "pick one" These are three different problems with three different consumers. Standardising on one style optimises for architectural tidiness at the expe
A partner reports your API fails from their servers with a certificate error. It works in every browser you try and from your laptop. Diagnose and prevent.
The diagnosis An incomplete certificate chain. The server presents its own certificate but not the intermediates. Browsers frequently recover — they cache inter
A payments API must guarantee that a network retry never charges a customer twice. Design the mechanism end to end.
Why this is unavoidable A client that times out on a POST cannot know whether the request succeeded. Not retrying risks a lost payment; retrying risks a duplica
A serverless API works in testing and fails under load with connection errors. The database is at 5% CPU. Explain and fix.
The mechanism Serverless functions scale by creating independent execution environments , each with its own process and its own connection pool. Two hundred con
A team is about to launch a public GraphQL API. What must be in place before it goes live?
Query cost control — the security requirement An arbitrary query language exposed publicly means a client can construct a query that consumes unbounded resource
A team proposes exposing their service's database change stream via CDC so other teams can consume it, avoiding the work of building an event API. What is your assessment?
Name what is actually being proposed The proposal is to publish the service's internal schema as its integration contract. CDC does not emit domain events; it e
A team proposes moving an API to edge functions to reduce latency for international users. What do you check before agreeing?
Where is the data? This is the question that settles most edge proposals. Compute at the edge that calls back to a single region database has moved the compute
A team wants to build a new internal API on serverless functions. It will serve steady traffic of about 200 requests per second during business hours. What do you advise?
What the interviewer is testing Whether you can apply the serverless trade off to a specific workload rather than treating it as a default good or a default bad
After moving a service behind a VPN to an on-premises system, small API calls succeed and large responses hang indefinitely. Walk through the diagnosis.
What the symptom tells you Size dependent failure with a working handshake is a very specific signature. The connection establishes, so routing, firewall rules,
An order API calls six services synchronously and takes 3 seconds at p95, failing whenever any dependency is degraded. Redesign it.
Diagnose with arithmetic Six synchronous dependencies at 99.9% each give 99.4% — roughly four hours a month, from components that are individually fine. And lat
Design an order submission API that is safe when the client cannot tell whether its request succeeded. What exactly do you store, and when?
What the interviewer is testing Whether you know that "make it idempotent" is a design with specific failure modes, not a checkbox. The core design The client g
Design rate limiting for a multi-tenant API where a single customer's traffic spike currently degrades service for everyone.
Name the problem precisely This is the noisy neighbour problem. Rate limiting is one control for it, and on its own it is incomplete — a customer within their l
Three teams keep breaking each other's services with API changes. Someone proposes contract testing. How do you introduce it without a six-month programme?
Start with one pair, not with the estate Pick the pair of services that has broken each other most recently. Instrument that one relationship end to end: the co
You are reviewing a new public API before launch. What do you check, in priority order?
1. Object level authorization — check this first, on every endpoint The most common serious API vulnerability. For each endpoint accepting an identifier, verify
You migrate a mobile API to HTTP/2 and p99 latency gets worse for users on cellular networks, while p50 improves. Explain and decide what to do.
The mechanism TCP head of line blocking. HTTP/2 multiplexes all streams onto one TCP connection. TCP guarantees ordered delivery, so a single lost packet stalls
You must make a breaking change to an API used by 200 internal services and 40 external partners. Design the change and the migration.
First, verify it must break Many "breaking" changes are avoidable. Adding a field is safe if clients ignore unknown fields — which should be a documented expect
Your API gateway configuration has grown to 8,000 lines with request transformations and cross-service orchestration. Changes require a platform team ticket and take two weeks. How do you fix this?
Name the failure The gateway has become a distributed monolith — shared, centrally owned, untestable in isolation, and on the critical path of every team's deli
API Shapes for UI
REST, GraphQL and RPC judged by over-fetching, round trips and client coupling.
API Error Handling
Error shapes, retryability signals and machine-readable causes.
API & Integration
General material on integrating systems through contracts.
API Documentation
OpenAPI as a machine-checked contract rather than as prose.
API Gateway
A single entry point for policy, routing and protocol translation.
API Gateways
The single entry point, and the business logic that must stay out of it.
API Versioning
URL, header and account-pinned versioning, and who carries the burden.
Platform API Deprecation
Removing something dozens of internal teams depend on, on a timeline that holds.
Secure API Design
Object-level authorisation, input validation and safe error responses.
Test Pyramid Shapes
Pyramid, trophy and honeycomb, and the system properties that justify each shape.
UI Monorepo Strategy
One repository for many front ends, and the build graph that makes it viable.
APIs as Products
Ownership, lifecycle, deprecation policy and developer experience.
Architecture Styles
System-level organising shapes, and how they differ from problem-level patterns.
Backward Compatibility
Which changes are safe, and how to make breakage a build failure.
Client State Architecture
Server state, UI state and derived state, and why conflating them causes most bugs.
Contract Testing
Verifying what consumers actually rely on, without a shared environment.
Contract Tests
Capturing what consumers actually use, not what the API documents.
Design Systems
Components as a versioned internal product, with adoption and deprecation like any API.
Event-Driven Integration
Publishing facts rather than commands, and versioning event schemas.