Introduction

While REST and GraphQL focus on request-response APIs, many applications require low-latency, high-performance, and event-driven communication. Remote Procedure Call (RPC) APIs and Event-Driven APIs serve these needs by enabling fast data exchange, inter-service communication, and real-time updates.

This guide explores RPC APIs (gRPC, JSON-RPC, and SOAP) and Event-Driven Architectures (WebSockets, Kafka, and Pub/Sub) using a detailed E-Commerce API example.

1. Understanding RPC vs REST vs GraphQL vs Event-Driven APIs

When to Use Each:

• Use REST when building traditional APIs with predictable resource-based operations.
• Use GraphQL when clients need flexible data fetching with complex relationships.
• Use RPC (gRPC) for microservices requiring fast, efficient communication.
• Use Event-Driven APIs when real-time streaming and async communication are critical.

2. RPC-Based API Design (gRPC, JSON-RPC, SOAP)

2.1. What is RPC?

Remote Procedure Call (RPC) allows clients to call functions on a remote server as if they were local functions. Unlike REST or GraphQL, RPC is function-oriented rather than resource-oriented.

2.2. gRPC (Google Remote Procedure Call)

Developed by Google, gRPC is an efficient binary protocol based on Protocol Buffers (protobufs), making it ideal for microservices and high-performance APIs.

Example: gRPC Schema for Product Service

syntax = "proto3";
package ecommerce;

service ProductService {
  rpc GetProduct (ProductRequest) returns (ProductResponse);
  rpc CreateProduct (CreateProductRequest) returns (ProductResponse);
}

message ProductRequest {
  string id = 1;
}

message ProductResponse {
  string id = 1;
  string name = 2;
  float price = 3;
}

message CreateProductRequest {
  string name = 1;
  float price = 2;
}

2.3. JSON-RPC (Lightweight RPC for Web APIs)

JSON-RPC is a lightweight RPC protocol using JSON over HTTP.

Example: JSON-RPC Request (Fetching a Product)

{
  "jsonrpc": "2.0",
  "method": "getProduct",
  "params": { "id": "123" },
  "id": 1
}

Response:

{
  "jsonrpc": "2.0",
  "result": {
    "id": "123",
    "name": "Laptop",
    "price": 1200.99
  },
  "id": 1
}

2.4. When to Use gRPC vs JSON-RPC?

3. Event-Driven API Design (WebSockets, Kafka, Pub/Sub)

3.1. What is an Event-Driven API?

Unlike request-response models (REST, GraphQL, RPC), event-driven APIs rely on publish-subscribe (Pub/Sub) messaging where services communicate asynchronously.

Common Event-Driven Technologies:

• WebSockets (bi-directional real-time updates)
• Kafka, RabbitMQ, NATS (message brokers for scalable event streaming)
• Google Pub/Sub, AWS SNS/SQS (cloud-based messaging)

3.2. WebSockets for Real-Time APIs

WebSockets allow persistent connections between client and server, enabling real-time updates.

Example: Order Status Updates via WebSockets

Client subscribes to order updates:

const socket = new WebSocket("wss://ecommerce.com/orders");
socket.onmessage = (event) => {
  console.log("Order Update: ", event.data);
};

Server pushes updates when the order status changes:

{
  "orderId": "501",
  "status": "Shipped"
}

3.3. Kafka for Scalable Event Streaming

Kafka is a distributed message broker used for high-throughput event-driven architectures.

Example: Order Events in Kafka

• Producer (Order Service) sends an event:

{
  "event": "OrderPlaced",
  "orderId": "501",
  "userId": "1",
  "total": 1299.98
}

• Consumer (Payment Service) processes the order event asynchronously.

Kafka enables scalable, event-driven microservices where services react to events instead of making direct API calls.

3.4. When to Use WebSockets vs Kafka vs Pub/Sub?

4. Implementing Event-Driven APIs in an E-Commerce System

4.1. Order Processing Example

• User places an order → Order Service publishes an event (OrderPlaced)
• Payment Service listens for OrderPlaced and processes payment
• Inventory Service listens for OrderPlaced and updates stock
• Notification Service listens and sends an email confirmation

4.2. Benefits of Event-Driven APIs in Microservices

✅ Loose coupling - Services don’t directly call each other. ✅ Scalability - Events can be processed by multiple consumers. ✅ Resilience - Services remain functional even if others fail.

Conclusion

RPC and Event-Driven APIs provide faster and more scalable alternatives to traditional REST/GraphQL APIs.

• Use gRPC or JSON-RPC for high-performance, low-latency service-to-service communication.
• Use WebSockets for real-time updates in chat apps, dashboards, or stock market feeds.
• Use Kafka or Pub/Sub for scalable event-driven microservices in large-scale systems.

By understanding when to use REST, GraphQL, RPC, and Event-Driven APIs, developers can design highly efficient and scalable systems.

This completes our 3-part API design series! 🚀