Why Monoliths are No Longer Enough, and What is gRPC For?
Deploying a massive monolith every time you need to fix a few lines of code is every backend engineer’s nightmare. That’s why we turn to microservices. However, as systems are broken down, services start “chatting” with each other too much, leading to new performance issues.
Where is the problem? Most developers still use REST APIs with JSON. While JSON is human-readable, it’s a heavy text-based format. Computers consume significant CPU cycles to serialize and deserialize it.
I once handled a payment system with about 5,000 requests per second. At that time, internal service latency hit record highs because JSON overhead was too large. After switching to gRPC, latency dropped by 40%, and the payload size shrank to just 1/3 of what it was before. Combined with Go‘s sharp concurrency handling, this is the perfect duo for high-load systems.
Two Pillars of gRPC’s Power
1. Protocol Buffers (Protobuf) – Small but Mighty
Think of Protobuf as a strict contract. You define the data structure once, and then tools automatically generate code for Go, Python, or Java. Because it transmits data in binary format, it’s extremely lightweight with almost zero conversion latency.
2. HTTP/2 – The Data Highway
Unlike the aging HTTP/1.1, HTTP/2 supports Multiplexing. You can send dozens of requests simultaneously over a single connection. This eliminates Head-of-line blocking, where one request has to wait for another to finish.
Hands-on: Building a Simple Calculator Service
To help you get the hang of it quickly, we’ll write a service that adds two numbers. Although simple, it covers all the most important steps in practice.
Step 1: Environment Setup
You need Go installed on your machine. Next, install the protoc compiler and the necessary plugins to generate code:
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latestStep 2: Designing the .proto File
Create the calculator.proto file. This is where we define the communication method between the Client and Server.
syntax = "proto3";
package calculator;
option go_package = "./pb";
message SumRequest {
int32 a = 1;
int32 b = 2;
}
message SumResponse {
int32 result = 1;
}
service CalculatorService {
rpc Sum(SumRequest) returns (SumResponse);
}Run this command to automatically generate Go code into the pb directory:
mkdir pb
protoc --go_out=. --go-grpc_out=. calculator.protoStep 3: Implementing the Server
We will implement the calculation logic. Create the server/main.go file:
package main
import (
"context"
"log"
"net"
"google.golang.org/grpc"
pb "your-module-path/pb"
)
type server struct {
pb.UnimplementedCalculatorServiceServer
}
func (s *server) Sum(ctx context.Context, req *pb.SumRequest) (*pb.SumResponse, error) {
return &pb.SumResponse{Result: req.A + req.B}, nil
}
func main() {
lis, err := net.Listen("tcp", ":50051")
if err != nil {
log.Fatalf("Port error: %v", err)
}
s := grpc.NewServer()
pb.RegisterCalculatorServiceServer(s, &server{})
log.Println("gRPC Server is running on port 50051...")
if err := s.Serve(lis); err != nil {
log.Fatalf("Server error: %v", err)
}
}Step 4: Writing the Client for Testing
Create the client/main.go file to test the service we just wrote:
package main
import (
"context"
"log"
"time"
"google.golang.org/grpc"
"google.golang.org/grpc/credentials/insecure"
pb "your-module-path/pb"
)
func main() {
conn, err := grpc.Dial("localhost:50051", grpc.WithTransportCredentials(insecure.NewCredentials()))
if err != nil {
log.Fatalf("Could not connect: %v", err)
}
defer conn.Close()
c := pb.NewCalculatorServiceClient(conn)
ctx, cancel := context.WithTimeout(context.Background(), time.Second)
defer cancel()
r, err := c.Sum(ctx, &pb.SumRequest{A: 10, B: 20})
if err != nil {
log.Fatalf("Function call error: %v", err)
}
log.Printf("Result: %d", r.GetResult())
}Hard-won Lessons from Working with gRPC
After several real-world projects, I’ve drawn three important lessons to avoid common pitfalls during operation:
- Use Standard Error Codes: Don’t just return a generic error. Use
codes.InvalidArgumentorcodes.NotFoundso the client knows exactly how to handle it. - Always Set Deadlines: In microservices, one hanging service can bring down the entire chain. Set a timeout (e.g., 500ms) for every request to keep the system resilient.
- Request Tracing: When you have 10 services calling each other, you won’t know where the error is without Jaeger or OpenTelemetry. Set them up from day one.
Applying a “Design-first” approach by finalizing the .proto file before coding helped my team increase productivity by 30%. Everyone agrees on data types from the start, ending arguments over whether a field should be a string or a number.
Conclusion
Go and gRPC not only make your system faster but also make your code more professional and organized. Although the initial setup is a bit more involved than REST, the bandwidth efficiency and speed it delivers are well worth it. Happy building, and may your systems run smoothly!
