Broker Pattern Flash Deck
Quick revision deck covering the Broker architecture pattern — foundations, components, invocation flow, scalability, security, observability, pitfalls, and best practices. Click a question to reveal the answer.
1. What core problem does the Broker pattern solve?
It decouples clients from services in large distributed systems, eliminating brittle point-to-point integrations and enabling location, protocol, and language transparency.
2. Why do direct client-service calls become brittle at scale?
Clients must hard-code endpoints, protocols, and cross-cutting concerns; changes or growth require touching every client; retries, authentication, and fail-over logic are duplicated.
3. Name three symptoms of 'point-to-point spaghetti'.
• Tight coupling
• Duplicated cross-cutting logic
• Chatty/over-frequent network calls
4. Client-side object that hides networking details.
Stub (proxy).
5. Server-side object that unpacks requests and invokes the real service.
Skeleton (server proxy).
6. Intermediary that routes, enforces policy, and returns responses.
Broker.
7. Service that maps logical names to live endpoints.
Naming / Registry service (e.g., Consul, DNS, ZooKeeper).
8. File that declares language-neutral service APIs.
IDL (Interface Definition Language).
9. What does code generation from an IDL produce?
Matched client stubs and server skeletons in multiple languages.
10. First step a client takes before calling a service via a broker.
Look up the service in the registry to resolve an endpoint.
11. What do stubs do with method calls before sending?
Marshal (serialize) the method name, parameters, and metadata into a request message.
12. What happens in the broker after receiving a marshalled request?
It selects an appropriate service instance (load balances) and forwards the request.
13. Final step before the client receives a return value.
Stub unmarshals the response and returns it as if it were a local call.
14. Difference between synchronous and asynchronous brokered calls.
Synchronous calls block until a response arrives; asynchronous calls return immediately and handle the result via callbacks, futures, or polling.
15. Term for a call where no reply is expected.
One-way / fire-and-forget.
16. Feature that allows multiple messages per invocation or duplex traffic.
Streaming (e.g., gRPC bidirectional streams).
17. What is location transparency?
Clients call a logical service name without knowing the host or port, letting services move or scale freely.
18. How does the broker enable language interoperability?
Via shared IDL definitions and generated stubs/skeletons in each language.
19. Mechanism supporting multiple API versions simultaneously.
Versioned registrations in the registry plus backward-compatible IDL evolution.
20. Two load-balancing strategies a broker might use.
• Round-robin
• Least-connections
21. Purpose of connection pooling in brokers or proxies.
Reuses established TCP/HTTP-2 channels to reduce handshake overhead and increase throughput.
22. Name three fault-tolerance techniques often built into brokers.
• Health checks
• Retries with back-off
• Circuit breakers
23. Where are authentication and authorization commonly enforced?
At the broker or a sidecar proxy, before forwarding the request.
24. How do brokers simplify transport encryption within a mesh?
They terminate external TLS and establish mutual TLS between proxies, sparing service code.
25. How can a broker support tenant isolation?
Routing or policy rules keyed by tenant ID plus per-tenant rate limits.
26. Three classes of telemetry brokers naturally collect.
• Metrics (latency, error rate)
• Distributed traces
• Access logs
27. What broker action mitigates a 'thundering herd' of requests?
Back-pressure or load shedding through rate limits, queuing, or dropping excess requests.
28. Google-origin RPC framework that embodies broker ideas via libraries.
gRPC (with xDS for discovery).
29. Cross-language RPC framework from Facebook, now Apache.
Apache Thrift.
30. Lightweight pub-sub system whose request-reply mode acts as a broker.
NATS.
31. Service-mesh data plane built on per-service proxies implementing broker duties.
Envoy (used by Istio, Linkerd, Kuma, etc.).
32. Message brokers that decouple producers and consumers asynchronously.
Apache Kafka, RabbitMQ, MQTT brokers (supporting RPC patterns via reply queues).
33. Term for excessive fine-grained remote calls harming performance.
Chatty interface anti-pattern.
34. Risk when all traffic transits a single or underscaled broker.
The broker becomes a bottleneck or single point of failure.
35. What is the 'God Broker' anti-pattern?
Overloading the broker with business logic, data transformation, or orchestration, making it monolithic and hard to evolve.
36. Why can interface changes still break systems despite the broker?
Clients and services remain tightly coupled to the shared API contract; breaking changes ripple across the system.
37. Operational cost often underestimated with brokers.
Need to deploy, upgrade, and monitor an additional infrastructure layer (or library versions across services).
38. Guideline for defining service operations to avoid chatty calls.
Prefer coarse-grained, purpose-focused methods or batch requests.
39. How to prevent a broker single point of failure.
Deploy multiple stateless broker instances and configure client fail-over.
40. Where should business orchestration live if not in the broker?
Dedicated application services or workflow engines; keep the broker focused on transport concerns.
41. Summarize the Broker pattern in one sentence.
An intermediary layer abstracts and manages all network communication details, letting services and clients evolve, scale, and interoperate cleanly.
42. Primary benefits delivered by brokers at scale.
• Decoupling and service discoverability
• Load balancing and fault tolerance
• Centralized security
• Unified observability
43. Single most important caution when adopting a broker.
Ensure it remains a lightweight, highly available transport layer — not a monolithic choke point.