Bird
Raised Fist0
Microservicessystem_design~10 mins

gRPC for internal communication in Microservices - Interactive Code Practice

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to define a gRPC service method.

Microservices
service UserService {
  rpc GetUser([1]) returns (UserResponse);
}
Drag options to blanks, or click blank then click option'
AUserRequest
BUserId
CUserResponse
DUserData
Attempts:
3 left
💡 Hint
Common Mistakes
Using the response message type as input.
Using a field name instead of a message type.
2fill in blank
medium

Complete the code to create a gRPC client stub in Go.

Microservices
conn, err := grpc.Dial(address, grpc.WithInsecure())
if err != nil {
  log.Fatalf("did not connect: %v", err)
}
defer conn.Close()
client := [1](conn)
Drag options to blanks, or click blank then click option'
ANewUserServiceClient
BNewGrpcClient
CNewClientStub
DNewServiceClient
Attempts:
3 left
💡 Hint
Common Mistakes
Using a generic or incorrect constructor function.
Forgetting to pass the connection object.
3fill in blank
hard

Fix the error in the server implementation to register the gRPC service.

Microservices
grpcServer := grpc.NewServer()
[1](grpcServer, &server{})
Drag options to blanks, or click blank then click option'
ARegisterUserServer
BRegisterGrpcServer
CRegisterService
DRegisterUserServiceServer
Attempts:
3 left
💡 Hint
Common Mistakes
Using a generic or incorrect registration function name.
Omitting the service implementation pointer.
4fill in blank
hard

Fill both blanks to define a unary gRPC method handler signature in Go.

Microservices
func (s *server) GetUser(ctx context.Context, [1] *UserRequest) (*UserResponse, [2]) {
  // implementation
}
Drag options to blanks, or click blank then click option'
Areq
Berr
Crequest
Derror
Attempts:
3 left
💡 Hint
Common Mistakes
Using incorrect parameter names.
Returning a non-error type as the second return value.
5fill in blank
hard

Fill all three blanks to create a gRPC client call and handle the response in Go.

Microservices
resp, [1] := client.GetUser(context.Background(), &[2]{})
if [3] != nil {
  log.Fatalf("could not get user: %v", err)
}
// use resp
Drag options to blanks, or click blank then click option'
Aerr
BUserRequest
Drequest
Attempts:
3 left
💡 Hint
Common Mistakes
Using inconsistent variable names for error.
Passing incorrect request message types.

Practice

(1/5)
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