Choose service boundaries, communication styles, API gateways, and service discovery patterns.
Distributed systems · architecture
Use the strong answer as your reference, explain it aloud in your own words, then choose how soon you want to review it again.
Interview prompt
Strong answer
Microservices trade in-process simplicity for independent deployment and team autonomy, so boundaries should follow business capabilities and data ownership rather than technical layers. Each service owns its data; other services interact through APIs or events, never through its tables. Choose synchronous calls (REST or gRPC) when the caller needs an immediate answer, and asynchronous messaging when work can complete later or many consumers react to the same fact. Gateways, discovery, and timeouts become first-class concerns.
Key points
Interviewer looks for
Justify a boundary with a concrete domain example, compare synchronous and asynchronous communication for that case, and explain what happens when a downstream service is slow or down.
Java example
1@HttpExchange("/api/inventory")
2interface InventoryClient {
3 @GetExchange("/{sku}")
4 StockLevel stock(@PathVariable String sku);
5}
6
7@Configuration
8class ClientConfig {
9 @Bean
10 InventoryClient inventoryClient(RestClient.Builder builder) {
11 var factory = new SimpleClientHttpRequestFactory();
12 factory.setConnectTimeout(Duration.ofMillis(500));
13 factory.setReadTimeout(Duration.ofSeconds(2));
14 RestClient client = builder
15 .baseUrl("http://inventory-service")
16 .requestFactory(factory)
17 .build();
18 return HttpServiceProxyFactory
19 .builderFor(RestClientAdapter.create(client))
20 .build()
21 .createClient(InventoryClient.class);
22 }
23}Topic interview questions
These questions are tied to this lesson. Read each question aloud, then compare your explanation with the strong answer.
Strong answer
Start from business capabilities and bounded contexts, keep data that changes together and has shared invariants in one service, and align services with team ownership. If two services always change and deploy together or need each other's tables, the boundary is probably wrong.
Strong answer
Use synchronous calls when the caller needs an answer to continue, such as a price check. Use messaging when work can complete later, many consumers react to one event, or you want to decouple availability. gRPC fits internal, high-throughput calls with strict schemas.
Strong answer
Shared tables couple services through schema, so one team's migration can break another and services cannot deploy independently. Owning data means other services access it through a contract, which makes ownership, scaling, and change explicit.
Strong answer
It provides a single entry point for routing, TLS termination, authentication, rate limiting, and request aggregation at the edge. It should not contain domain logic, or it becomes a coupling point that every team must change.
Strong answer
Set connect and read timeouts, bound concurrency with bulkheads, add a circuit breaker to fail fast, retry only idempotent calls with backoff and jitter, and define a fallback or degraded response. Monitor the dependency's latency so problems are visible early.
How well do you know this?
Your review choice is saved locally and synced to your learner profile when signed in.