Performance Comparison of REST, gRPC, and Asynchronous Communication in Microservices

Microservice communication methods significantly affect both functional and non‑functional quality attributes such as performance, scalability, and maintainability.

Data Transfer Format

Although asynchronous communication using AMQP and gRPC use binary protocols, REST APIs typically transfer data as text. Binary protocols are far more efficient, resulting in lower network load for gRPC and AMQP compared with REST.

Connection Handling

REST APIs are built on HTTP/1.1, while gRPC relies on HTTP/2. Both HTTP/1.1, HTTP/2 and AMQP use TCP. HTTP/2 and AMQP support multiplexing, allowing a single connection to be reused for multiple requests, whereas REST over HTTP/1.1 creates a new connection for each request.

Message Serialization

REST and asynchronous communication typically serialize messages as JSON, while gRPC uses Protocol Buffers, which provide faster serialization and deserialization. However, JSON remains human‑readable for debugging.

Cache

REST APIs can be effectively cached by proxies such as Varnish, reducing server load and enabling high HTTP traffic handling. gRPC and AMQP specifications do not define caching mechanisms.

Load Balancing

Load balancers like mod_proxy can distribute HTTP traffic for REST services, and Kubernetes can balance HTTP/1.1 traffic automatically. gRPC requires an additional service (e.g., Linkerd) for load balancing, while AMQP brokers act as built‑in load balancers.

Experiment

Four Go microservices were deployed on a self‑hosted Kubernetes cluster (three nodes, 1 Gbit network, 0.15 ms latency) to simulate an e‑commerce order scenario. Business logic was replaced by a fixed 100 ms delay, resulting in a total communication latency of 400 ms. Load testing was performed with k6.

Implementation

REST server uses Go’s net/http and encoding/json packages:

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io/ioutil"
    "log"
    "net/http"

    "github.com/google/uuid"
    "gitlab.com/timbastin/bachelorarbeit/common"
    "gitlab.com/timbastin/bachelorarbeit/config"
)

type restServer struct {
    httpClient http.Client
}

// handler implementation...

Asynchronous communication uses RabbitMQ via the streadway/amqp library:

package main

import (
    "encoding/json"
    "log"

    "github.com/streadway/amqp"
    "gitlab.com/timbastin/bachelorarbeit/common"
    "gitlab.com/timbastin/bachelorarbeit/config"
    "gitlab.com/timbastin/bachelorarbeit/utils"
)

// handleMsg, getNewOrderChannel, startAmqpServer implementations...

gRPC server uses google.golang.org/grpc and Protocol Buffers:

package main

import (
    "log"
    "net"

    "context"

    "gitlab.com/timbastin/bachelorarbeit/common"
    "gitlab.com/timbastin/bachelorarbeit/config"
    "gitlab.com/timbastin/bachelorarbeit/pb"
    "gitlab.com/timbastin/bachelorarbeit/utils"
    "google.golang.org/grpc"
)

// OrderServiceServer implementation...

Data Collection

Successful and failed order processing times were measured; orders taking longer than 900 ms were considered failures. Tests were run under low (10), medium (100), and high (300) concurrent request loads, with varying payload sizes.

Results

gRPC demonstrated the best performance, handling 3.41 × more orders than REST under low load and achieving average response times 9.71 ms lower than REST and 9.37 ms lower than AMQP.