gRPC for internal communication in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why choose gRPC over REST for internal microservice communication?

Consider a system where multiple microservices communicate internally. Which of the following is the main advantage of using gRPC instead of REST for this internal communication?

A gRPC only supports synchronous communication, which simplifies service design.

B gRPC uses HTTP/2 which allows multiplexing multiple requests over a single connection, reducing latency.

C gRPC requires no schema definition, so services can evolve independently without coordination.

D gRPC messages are always human-readable JSON, making debugging easier than REST.

💡 Hint

Think about how network efficiency and protocol features affect communication speed and resource use.

gRPC uses HTTP/2 which supports multiplexing multiple requests on a single connection, reducing latency and improving throughput compared to REST which typically uses HTTP/1.1. This makes gRPC efficient for internal microservice communication.

❓ Architecture

intermediate

Designing service discovery with gRPC in microservices

You have multiple microservices communicating via gRPC. Which approach best supports dynamic service discovery to handle scaling and failures?

A Let clients broadcast requests to all possible service instances and accept the first response.

B Hardcode all service IP addresses in client configurations to avoid runtime lookups.

C Use a centralized service registry where services register their addresses; clients query this registry before making gRPC calls.

D Use DNS round-robin with static IPs for all services without any registry.

💡 Hint

Think about how services can find each other reliably when instances change dynamically.

A centralized service registry allows services to register their current addresses and clients to discover them dynamically. This supports scaling and failure handling better than static configurations or broadcasting.

❓ scaling

advanced

Handling high load with gRPC streaming in microservices

Your microservice needs to send a continuous stream of updates to clients using gRPC. What is the best way to handle backpressure and avoid overwhelming clients?

A Implement client-side flow control by using gRPC's built-in flow control mechanisms to regulate message rates.

B Send all updates as fast as possible and rely on clients to buffer messages.

C Use multiple parallel gRPC streams per client to increase throughput without flow control.

D Switch to REST polling instead of streaming to avoid backpressure issues.

💡 Hint

Consider how gRPC supports managing message flow between sender and receiver.

gRPC supports flow control in streaming RPCs, allowing clients to control how many messages they can handle. This prevents overwhelming clients and manages backpressure effectively.

❓ tradeoff

advanced

Tradeoffs of using gRPC with Protocol Buffers vs JSON over HTTP for internal APIs

Which of the following is a correct tradeoff when choosing gRPC with Protocol Buffers over JSON/HTTP for internal APIs?

A gRPC does not support streaming, so JSON/HTTP is better for real-time data.

B gRPC with Protocol Buffers is easier to debug with plain text messages compared to JSON.

C JSON/HTTP APIs are faster than gRPC because JSON parsing is simpler than Protocol Buffers decoding.

D gRPC with Protocol Buffers offers better performance and smaller message size but requires strict schema management.

💡 Hint

Think about message size, speed, and schema requirements.

gRPC uses Protocol Buffers which are compact and fast but require predefined schemas. JSON is human-readable and flexible but larger and slower to parse.

❓ estimation

expert

Estimating capacity for gRPC internal communication in a microservice system

You have 100 microservice instances communicating via gRPC. Each instance sends 50 requests per second to 10 other instances. Each request message is 2KB and response is 3KB. Estimate the total network bandwidth needed for gRPC communication in Mbps.

A Approximately 200 Mbps

B Approximately 80 Mbps

C Approximately 120 Mbps

D Approximately 300 Mbps

💡 Hint

Calculate total messages per second and multiply by message sizes, then convert bytes to bits and to Mbps.

Total requests per second = 100 instances * 50 requests/sec * 10 targets = 50,000 requests/sec.
Each request + response size = 2KB + 3KB = 5KB = 5 * 1024 bytes = 5120 bytes.
Total bytes per second = 50,000 * 5120 = 256,000,000 bytes/sec.
Convert to bits: 256,000,000 * 8 = 2,048,000,000 bits/sec.
Convert to Mbps: 2,048,000,000 / 1,000,000 = 2048 Mbps, which is much higher than the options given.

Practice

1. What is the main advantage of using gRPC for internal communication between microservices?

easy

A. It requires no predefined message formats.

B. It provides fast, efficient, and strongly typed communication.

C. It only works with services written in the same language.

D. It uses plain text messages for easy debugging.

Solution

1. Step 1: Understand gRPC communication benefits

   gRPC uses Protocol Buffers which are compact and strongly typed, making communication fast and reliable.

2. Step 2: Compare with other options

   Options B, C, and D are incorrect because gRPC requires predefined message formats, supports multiple languages, and uses binary messages, not plain text.

3. Final Answer:

   It provides fast, efficient, and strongly typed communication. -> Option B

4. Quick Check:

   gRPC speed and typing [OK]

Hint: gRPC is fast and typed, unlike plain text or language-specific methods [OK]

Common Mistakes:

• Thinking gRPC uses plain text messages
• Assuming gRPC works only with one language
• Believing gRPC needs no message definitions

2. Which of the following is the correct way to define a gRPC service method in a .proto file?

easy

A. method GetUser returns UserResponse(UserRequest);

B. service GetUser { rpc UserRequest returns UserResponse; }

C. rpc GetUser (UserRequest) returns (UserResponse);

D. function GetUser(UserRequest): UserResponse;

Solution

1. Step 1: Recall gRPC .proto syntax

   In .proto files, service methods are defined using the syntax: rpc MethodName (RequestType) returns (ResponseType);

2. Step 2: Validate options

   rpc GetUser (UserRequest) returns (UserResponse); matches the correct syntax. Options B, C, and D do not follow the .proto syntax for defining rpc methods.

3. Final Answer:

   rpc GetUser (UserRequest) returns (UserResponse); -> Option C

4. Quick Check:

   .proto rpc syntax [OK]

Hint: Remember: rpc Method(Request) returns (Response); in .proto files [OK]

Common Mistakes:

• Using 'service' keyword incorrectly for methods
• Confusing method syntax with programming language functions
• Omitting parentheses around request and response types

3. Given the following gRPC client call in Python, what will be the output if the server returns a UserResponse with name='Alice' and age=30?

response = stub.GetUser(UserRequest(id=123))
print(f"Name: {response.name}, Age: {response.age}")

medium

A. Name: Alice, Age: 30

B. Name: 123, Age: 0

C. Name: , Age:

D. Error: stub.GetUser is not a function

Solution

1. Step 1: Understand the client call and server response

   The client calls GetUser with id=123. The server responds with UserResponse containing name='Alice' and age=30.

2. Step 2: Analyze the print statement output

   The print statement accesses response.name and response.age, so it will output the values returned by the server.

3. Final Answer:

   Name: Alice, Age: 30 -> Option A

4. Quick Check:

   Client prints server response fields [OK]

Hint: Client prints server response fields directly as returned [OK]

Common Mistakes:

• Assuming client sends back request data instead of server response
• Confusing method call syntax causing errors
• Expecting empty or default values without server response

4. A developer wrote this gRPC service definition but the client fails to connect:

service UserService {
  rpc GetUser UserRequest returns UserResponse;
}

What is the error in this definition?

medium

A. Missing parentheses around request and response types.

B. Service name should be lowercase.

C. rpc keyword should be capitalized as RPC.

D. UserRequest and UserResponse must be strings.

Solution

1. Step 1: Check gRPC method syntax in .proto

   The correct syntax requires parentheses around request and response types: rpc MethodName (RequestType) returns (ResponseType);

2. Step 2: Identify the error in the given code

   The code misses parentheses around UserRequest and UserResponse, causing client connection failure.

3. Final Answer:

   Missing parentheses around request and response types. -> Option A

4. Quick Check:

   Parentheses required in rpc method signature [OK]

Hint: Always use parentheses around request and response in rpc methods [OK]

Common Mistakes:

• Ignoring parentheses in rpc method definitions
• Thinking service names must be lowercase
• Misunderstanding rpc keyword casing rules

5. You have multiple microservices written in different languages that need to communicate internally with low latency and strict message contracts. Which approach best fits this scenario?

hard

A. Use REST APIs with JSON for all communication.

B. Use message queues with XML messages.

C. Use plain TCP sockets with custom binary protocol.

D. Use gRPC with Protocol Buffers for internal communication.

Solution

1. Step 1: Analyze requirements for low latency and strict contracts

   Low latency and strict message contracts require efficient, strongly typed communication.

2. Step 2: Evaluate communication options

   REST with JSON is flexible but slower and less strict. Plain TCP with custom protocol is complex and error-prone. Message queues add latency and XML is verbose. gRPC with Protocol Buffers is designed for efficient, strongly typed, multi-language communication.

3. Final Answer:

   Use gRPC with Protocol Buffers for internal communication. -> Option D

4. Quick Check:

   Low latency + strict contracts = gRPC [OK]

Hint: gRPC + Protobuf = fast, typed, multi-language communication [OK]

Common Mistakes:

• Choosing REST despite latency and typing needs
• Using custom protocols without standard tooling
• Ignoring message size and parsing overhead