gRPC for internal services in HLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why choose gRPC over REST for internal services?

Consider a company deciding between gRPC and REST for communication between its internal microservices. Which of the following is the main advantage of using gRPC in this context?

A gRPC uses HTTP/2 which supports multiplexing and reduces latency compared to REST over HTTP/1.1

B gRPC only supports synchronous calls, which simplifies service design

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 protocol efficiency and network features.

gRPC uses HTTP/2 which allows multiplexing multiple calls over a single connection, reducing latency and improving performance compared to REST which typically uses HTTP/1.1.

❓ Architecture

intermediate

Designing service communication with gRPC

You are designing an internal system with multiple microservices. Which architectural pattern best fits gRPC usage for service-to-service communication?

A Use gRPC to expose public APIs directly to external clients

B Use gRPC for synchronous request-response calls between services with defined protobuf contracts

C Use gRPC as a replacement for database queries within services

D Use gRPC only for asynchronous event streaming and avoid request-response patterns

💡 Hint

Consider typical gRPC usage patterns inside microservice architectures.

gRPC is ideal for synchronous request-response communication between internal services using protobuf contracts to define messages and services.

❓ scaling

advanced

Scaling gRPC services under high load

Your internal gRPC service is experiencing high traffic and latency spikes. Which approach best helps scale the service efficiently?

A Switch to REST APIs to reduce overhead from HTTP/2 multiplexing

B Increase the size of protobuf messages to reduce the number of calls

C Implement client-side load balancing with multiple service instances and use connection pooling

D Disable streaming features to simplify the protocol

💡 Hint

Think about how gRPC clients can distribute load and reuse connections.

Client-side load balancing with multiple instances and connection pooling helps distribute requests and reduce latency under high load.

❓ tradeoff

advanced

Tradeoffs of using gRPC streaming internally

What is a key tradeoff when using gRPC streaming for internal service communication?

A Streaming reduces latency but increases complexity in error handling and resource management

B Streaming always improves throughput without any drawbacks

C Streaming eliminates the need for service discovery

D Streaming requires all clients to be implemented in the same programming language

💡 Hint

Consider the operational challenges of long-lived connections.

While streaming can reduce latency and improve throughput, it adds complexity in managing connection lifecycle, errors, and resource usage.

❓ estimation

expert

Estimating capacity for gRPC internal services

You expect 10,000 requests per second to your internal gRPC service. Each request takes 5ms to process on average. How many service instances do you need to handle the load without queuing, assuming each instance can handle requests sequentially?

A At least 200 instances

B At least 500 instances

C At least 1000 instances

D At least 50 instances

💡 Hint

Calculate how many requests one instance can handle per second, then divide total requests by that.

One instance handles 1 / 0.005 = 200 requests per second. For 10,000 requests, 10,000 / 200 = 50 instances are needed to handle the load without queuing.