5 exercises — Practice gRPC and Protobuf vocabulary in English: .proto file, message types, field numbers, stubs, channels, streaming RPC patterns, status codes, interceptors, and deadlines.
Streaming: unary RPC, server streaming, client streaming, bidirectional streaming
Operations: status codes (OK, UNAVAILABLE, DEADLINE_EXCEEDED), interceptor, deadline/timeout, health check protocol
0 / 13 completed
1 / 13
A backend engineer introduces gRPC to a team migrating from REST: "gRPC is a high-performance RPC framework from Google. Instead of JSON over HTTP/1.1, we use Protocol Buffers for serialization and HTTP/2 for transport. You define your service and messages in a .proto file — this is the contract. The protoc compiler generates client stubs and server interfaces in your language of choice. The stub is what the client calls — it looks like a local function call but actually makes a network RPC. The channel is the connection to the server, managing HTTP/2 multiplexing, load balancing, and TLS." What is a stub in gRPC and how does it relate to the .proto file?
Stub (generated client): when you run protoc with the gRPC plugin on a .proto file, it generates two things: (1) message classes for serialization/deserialization, (2) stub classes for the client and base classes for the server. The stub encapsulates: serialize request to Protobuf binary, open HTTP/2 stream on the channel, send request, receive response bytes, deserialize to response message type. .proto file structure: syntax = "proto3"; — declares proto3 syntax. package: namespacing. message: defines a data type. service: defines an RPC interface. rpc: declares a method. Protobuf field numbers: each field has a number (1, 2, 3...). This number is used in the binary encoding, not the field name. Field numbers 1-15 use one byte in encoding. Never change existing field numbers — breaks wire compatibility. Wire format vocabulary: Varint: variable-length integer encoding. Length-delimited: for strings, bytes, embedded messages. In conversation: 'The stub is magic — it makes calling a service in another language on another continent look like calling a local function. The .proto is the contract that makes that possible.'
2 / 13
A senior engineer explains gRPC streaming to a developer building a real-time chat service: "gRPC has four RPC patterns. Unary is like REST: one request, one response. Server streaming: you send one request, the server sends back a stream of responses — great for live feeds. Client streaming: you send a stream of requests, get one response — good for file uploads. Bidirectional streaming: both sides send streams simultaneously over one HTTP/2 connection — perfect for chat or collaborative editing. HTTP/2 multiplexes all of this on a single TCP connection, unlike HTTP/1.1 which needs a new connection per request." What makes bidirectional streaming RPC possible in gRPC but not in standard REST?
HTTP/2 multiplexing: HTTP/2 introduces streams — multiple independent request-response sequences sharing one TCP connection. Each stream has a unique ID. Frames from different streams are interleaved. gRPC maps each RPC call to an HTTP/2 stream. Bidirectional streaming: both client and server can send frames on their respective streams at any time. .proto streaming syntax: rpc Chat(stream ChatMessage) returns (stream ChatMessage); — both request and response are streams. Four patterns: Unary: one request, one response. Server streaming: one request, stream of responses. Client streaming: stream of requests, one response. Bidi streaming: streams in both directions. HTTP/2 benefits for gRPC: header compression (HPACK), binary framing, flow control. gRPC-Web: browser clients cannot use gRPC directly. gRPC-Web is a translation layer (Envoy proxy) that adapts for browser fetch/XHR. In conversation: 'For internal service-to-service calls, gRPC bidi streaming eliminated our polling architecture entirely. Latency dropped from 200ms polling to sub-5ms push latency.'
3 / 13
An SRE explains a production timeout incident caused by a missing gRPC configuration: "The recommendation service call was hanging. The ML model it called occasionally takes 30 seconds on a cold cache. Our client had no deadline set — it waited indefinitely, holding a thread. Under load, all threads were blocked waiting for the ML service. The fix: set a deadline of 500ms on every gRPC call. If the ML service doesn't respond in time, we return a DEADLINE_EXCEEDED status and show a fallback. Never make a gRPC call without a deadline — it's the same as writing a network call with no timeout." What is a deadline in gRPC and why is it preferable to a simple timeout?
Deadline: an absolute timestamp by which the entire operation must complete. Passed in the gRPC context. When ServiceA calls ServiceB calls ServiceC, the deadline propagates — each downstream service sees the remaining time budget. If the deadline passes, the call is cancelled at all levels simultaneously. Timeout: a duration relative to the current call. Does not propagate — each service in a chain might set its own timeout. gRPC status codes: OK (0): success. CANCELLED (1): operation cancelled. DEADLINE_EXCEEDED (4): deadline expired. NOT_FOUND (5): entity not found. PERMISSION_DENIED (7): caller lacks permission. RESOURCE_EXHAUSTED (8): quota/rate limit. UNAVAILABLE (14): service unavailable — safe to retry. UNAUTHENTICATED (16): not authenticated. In conversation: 'Always propagate the context with its deadline to downstream calls. One gRPC call that hangs indefinitely can cascade into thread-pool exhaustion across your entire service mesh.'
4 / 13
A developer explains a backward compatibility issue discovered during API evolution: "We removed the 'phone_number' field from the User message and freed field number 4 for a new field 'profile_picture_url'. Old clients started getting garbled data — 'profile_picture_url' was being deserialized as 'phone_number'. Protobuf uses field numbers for encoding, not field names. Reusing field number 4 was the mistake. We should have used 'reserved 4; reserved "phone_number";' to prevent future misuse. Lesson: never reuse field numbers." Why are field numbers in Protobuf critical for backward compatibility?
Protobuf wire format: each field is encoded as (field_number << 3 | wire_type), followed by the value. Field names are NOT in the binary encoding. An old decoder seeing field 4 uses its schema to interpret it. Safe Protobuf changes: add new fields (old code ignores unknown fields), remove optional fields (new code gets default). Unsafe changes: change field type, change field number, reuse a field number. reserved keyword: reserved 4; reserved "phone_number"; prevents both the number and name from being reused. The compiler errors if you try. Proto3 default values: missing fields get language defaults — 0 for numbers, "" for strings, false for bool. Use google.protobuf.Int32Value wrapper for nullable scalars. Well-known types: Timestamp, Duration, Struct, Any, FieldMask — standard Protobuf types for common patterns. In conversation: 'Field numbers are forever. Document removed fields with reserved. It takes 30 seconds and saves hours of debugging mismatched data across service versions.'
5 / 13
A platform engineer explains gRPC interceptors during a developer onboarding session: "We use interceptors — gRPC's equivalent of middleware — for all our cross-cutting concerns. There's an auth interceptor that validates JWT tokens on every inbound call. A logging interceptor that records every request: method name, latency, status code. A tracing interceptor that starts an OpenTelemetry span and propagates trace context to downstream calls. A retry interceptor on the client side that retries UNAVAILABLE errors with exponential backoff. Interceptors chain — each wraps the next, passing down the context." What is a gRPC interceptor and what is it used for?
gRPC interceptor: analogous to middleware in web frameworks. Wraps the RPC handler in a chain. Types: Unary interceptor: wraps single request-response RPCs. Stream interceptor: wraps streaming RPCs. Client-side: runs in the caller's process before sending. Server-side: runs in the server's process before the handler. Common patterns: Auth interceptor (server-side): extract token from metadata, validate, attach user context. Return UNAUTHENTICATED if invalid. Logging interceptor: log method name, peer address, status code and latency. Tracing interceptor: start span, extract/inject trace context headers (W3C Trace Context). Retry interceptor (client-side): on UNAVAILABLE, retry with exponential backoff. gRPC metadata vocabulary: Metadata: key-value pairs sent with an RPC, analogous to HTTP headers. Used for: auth tokens, trace IDs, client version. Trailing metadata: sent by server after the response body (HTTP/2 trailers). gRPC health check protocol: standard proto that servers implement to report readiness. Used by Kubernetes probes and load balancers. In conversation: 'Interceptors are where your operational concerns live. The handler should be pure business logic. Authentication, tracing, retry — interceptors.'
6 / 13
Review this code review comment: 'The gRPC client is calling the service without specifying any metadata. This could impact performance and potentially allow us to add custom headers for tracing or authentication in the future.' What does the reviewer mean by 'metadata' in the context of a gRPC call?
The reviewer is referring to HTTP/2 metadata – essentially, headers attached to the underlying connection. These can be used for various purposes like tracing or authentication without modifying the core Protobuf message structure. This highlights a potential future-proofing consideration when designing gRPC services.
7 / 13
Sarah (Frontend Dev) sends this Slack message: 'Just deployed the new profile update endpoint! It's using Protocol Buffers for efficient serialization and HTTP/2 for transport. We're sending a User object with all the new fields.' Which of the following best describes Sarah's primary reason for choosing Protocol Buffers?
Sarah's choice of Protocol Buffers is driven by its efficiency in serializing structured data. Protobuf's binary format and field number encoding are significantly more compact than JSON, leading to smaller message sizes and faster serialization/deserialization – crucial for performance, especially with HTTP/2. It's about efficient data representation.
8 / 13
The following is a simplified gRPC response from the 'User Service': `{
"code": 200,
"message": "User updated successfully",
"data": {
"user_id": 123,
"username": "john.doe",
"email": "john@example.com"
}
}`. What does the 'code' field in this response indicate?
The `code` field in this gRPC response corresponds directly to the HTTP status code (200 in this case). gRPC leverages HTTP/2 under the hood, so it uses standard HTTP status codes to communicate the result of the request. This is a common practice when building gRPC services.
9 / 13
Mark (Backend Engineer) comments on a PR: 'Hey team, noticed you're using gRPC here. To ensure optimal performance, could we add metadata to the client calls? Specifically, adding a custom header for tracing would greatly assist with debugging latency issues.' What is Mark referring to?
Mark is discussing metadata in the context of gRPC. Metadata allows you to add custom information alongside your requests – in this case, for tracing and monitoring performance. While Protocol Buffers are fundamental, the specific issue here revolves around *how* the client interacts with the service, not just the data format itself. Adding metadata is a common practice when optimizing gRPC calls.
10 / 13
Liam (SRE) sends a Slack message: 'We're seeing a spike in timeouts on the recommendation service. The underlying ML model takes an average of 30 seconds to generate results when the cache is cold. Our gRPC client isn't handling these long delays effectively.' What potential issue does Liam highlight?
Liam points out a critical design flaw: the gRPC client isn't addressing the inherent latency of the ML model when the cache is cold. This highlights the importance of understanding dependencies and implementing appropriate timeouts or retry strategies within the client to avoid indefinite blocking. Simply having a gRPC connection doesn't solve performance problems – you need to handle the service's response times.
11 / 13
Chloe (Platform Engineer) is explaining interceptors during a team meeting: 'Think of gRPC interceptors as middleware. They allow us to add functionality like authentication or logging without modifying the core service logic.' Which of the following best describes the primary purpose of using interceptors?
Interceptors in gRPC serve as middleware – they provide a way to add functionality (like authentication or logging) without altering the core service logic itself. This promotes modularity and maintainability. While Protocol Buffers are important, interceptors operate at a higher level of abstraction within the gRPC call chain.
12 / 13
David (Code Reviewer) writes in a comment: 'The gRPC service is returning a 200 status code even though the user update failed internally. Consider adding more detailed error handling to the response message.' What does David recommend?
David correctly identifies a problem with the gRPC service's response: returning a 200 OK status code when an error occurred is misleading. A good practice is to return more descriptive error responses that include specific details about the failure, allowing the client to handle it appropriately. This aligns with standard HTTP conventions.
13 / 13
Emily (Frontend Developer) describes a new feature: 'We're leveraging Protocol Buffers for efficient serialization when sending user profile updates. The message structure includes fields like user_id and username, serialized efficiently using Protobuf to minimize bandwidth usage.' Which aspect does Emily primarily emphasize?
Emily focuses on the core advantage of using Protocol Buffers: their efficient data serialization format. This is key to minimizing bandwidth usage when sending data over the network – a critical consideration for performance and cost-effectiveness. While HTTP/2 is involved, the primary emphasis is on Protobuf's compression capabilities.
What does the "gRPC & Protocol Buffers Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to grpc & protocol buffers vocabulary through 13 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 13 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 2 other vocabulary modules. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.