Differences between REST, gRPC, and Kafka

package com.bank.controller;

import com.bank.model.Account;
import com.bank.service.AccountService;
import org.springframework.web.bind.annotation.*;
import java.math.BigDecimal;

@RestController
@RequestMapping("/api/v1/accounts")
public class AccountController {

    private final AccountService accountService;

    public AccountController(AccountService accountService) {
        this.accountService = accountService;
    }

    @GetMapping("/{accountId}/balance")
    public BigDecimal getBalance(@PathVariable String accountId) {
        return accountService.getBalance(accountId);
    }
}

GET /api/v1/accounts/SAV2001/balance
Content-Type: application/json

Response: 75000.00
Payload size: ~45 bytes (JSON text)
Latency: ~8ms (HTTP/1.1, new connection)

// account_service.proto
syntax = "proto3";
package com.bank.grpc;

service AccountService {
    rpc GetBalance (BalanceRequest) returns (BalanceResponse);
    rpc StreamTransactions (AccountRequest) returns (stream Transaction);
}

message BalanceRequest {
    string account_id = 1;
}

message BalanceResponse {
    string account_id = 1;
    string balance = 2;
}

message AccountRequest {
    string account_id = 1;
}

message Transaction {
    string txn_id = 1;
    string amount = 2;
    string type = 3;
}

package com.bank.client;

import com.bank.grpc.AccountServiceGrpc;
import com.bank.grpc.BalanceRequest;
import com.bank.grpc.BalanceResponse;
import io.grpc.ManagedChannel;
import java.math.BigDecimal;

public class GrpcBalanceClient {

    private final AccountServiceGrpc.AccountServiceBlockingStub stub;

    public GrpcBalanceClient(ManagedChannel channel) {
        this.stub = AccountServiceGrpc.newBlockingStub(channel);
    }

    public BigDecimal getBalance(String accountId) {
        BalanceResponse response = stub.getBalance(
                BalanceRequest.newBuilder()
                        .setAccountId(accountId)
                        .build());
        return new BigDecimal(response.getBalance());
    }
}

// gRPC call for SAV2001:
// Request: ~12 bytes (binary protobuf)
// Response: ~18 bytes (binary protobuf)
// Latency: ~2ms (HTTP/2 multiplexed connection)

package com.bank.producer;

import com.bank.event.PaymentEvent;
import org.springframework.kafka.core.KafkaTemplate;
import org.springframework.stereotype.Service;
import java.math.BigDecimal;

@Service
public class PaymentEventProducer {

    private final KafkaTemplate<String, PaymentEvent> kafkaTemplate;

    public PaymentEventProducer(KafkaTemplate<String, PaymentEvent> kafkaTemplate) {
        this.kafkaTemplate = kafkaTemplate;
    }

    public void publishPaymentCompleted(String accountId, BigDecimal amount) {
        PaymentEvent event = new PaymentEvent(
                "PAY-" + System.currentTimeMillis(),
                accountId, amount, "COMPLETED");
        // Fire and forget: returns immediately
        kafkaTemplate.send("payment-events", accountId, event);
    }
}

// Producer publishes to topic "payment-events" keyed by SAV2001
// Returns in ~2ms
// Consumer group "notification": reads and sends SMS
// Consumer group "fraud": reads and scores the transaction
// Consumer group "analytics": reads and updates the dashboard
// If fraud consumer is down, messages wait in the partition

package com.bank.service;

import java.math.BigDecimal;

public class TransferFlow {

    // REST: mobile app calls the gateway
    // POST /api/v1/transfers {from: "SAV2001", to: "SAV3002", amount: 50000}

    // gRPC: gateway calls Account Service internally (fast, typed)
    // accountStub.debit(DebitRequest{accountId: "SAV2001", amount: "50000"})

    // Kafka: after success, publish event for fan-out
    // kafkaTemplate.send("transfer-events", "SAV2001", event)

    // REST  → universality (browser/mobile)
    // gRPC  → speed (internal, millions of calls/day)
    // Kafka → decoupling (notification, fraud, audit react independently)
}

// REST limitation: large JSON payload for batch operations
// GET /api/v1/accounts/SAV2001/transactions?limit=1000
// Response: ~500KB of JSON text

// gRPC advantage: same data in protobuf ~150KB (binary, no field names)

// Kafka limitation: no synchronous reply
// WRONG: publish request to Kafka, poll for reply
// CORRECT: use REST or gRPC for synchronous answers

// WRONG: using REST for everything, including high-frequency internal calls
// Account Service calls Fraud Service 50,000 times/second over REST
// Each call: ~45 bytes JSON, HTTP/1.1 overhead, new connection
// Total overhead: massive

// CORRECT: use gRPC for that internal path
// Each call: ~12 bytes protobuf, HTTP/2 multiplexed
// Same data, fraction of the cost

// WRONG: using Kafka for a balance query
// Publish to "balance-request" topic, poll "balance-response" topic
// Slow, fragile, misuses an event log as a request-response channel

// CORRECT: use REST or gRPC for queries
// BigDecimal balance = accountStub.getBalance(request);

// Senior pattern: layered communication
// Layer 1: REST at the public edge (universality)
// Layer 2: gRPC between internal services (speed, typing)
// Layer 3: Kafka as the event backbone (decoupling, replay)

// Key Kafka messages by aggregate ID for ordering
kafkaTemplate.send("payment-events", "SAV2001", event);
// All events for SAV2001 land on the same partition → consumed in order