I’ve been thinking a lot about how modern applications handle complex workflows. Why do some systems scale effortlessly while others crumble under pressure? The answer often lies in event-driven architecture. Today, I’ll walk you through building a complete event-driven microservice system using Go, NATS, and gRPC - the exact stack powering production systems at companies like Docker and Cloudflare.

First, let’s set up our project. Create a new directory and initialize Go modules:

mkdir event-driven-microservices
cd event-driven-microservices
go mod init github.com/yourname/event-driven-microservices

Our directory structure organizes services cleanly:

├── cmd/
│   ├── order-service/
│   ├── payment-service/
│   ├── inventory-service/
│   └── notification-service/
├── internal/
│   ├── order/
│   ├── payment/
│   ├── inventory/
│   ├── notification/
│   └── shared/
├── pkg/
│   ├── events/
│   ├── grpc/
│   └── nats/
├── proto/
├── docker-compose.yml
└── Makefile

Install essential dependencies:

go get google.golang.org/grpc \
github.com/nats-io/nats.go \
go.opentelemetry.io/otel \
github.com/sony/gobreaker \
gorm.io/gorm

Events form the backbone of our system. Let’s define our event schema in pkg/events/events.go:

package events

type EventType string

const (
    OrderCreated     EventType = "order.created"
    PaymentProcessed EventType = "payment.processed"
    // Additional event types
)

type Event struct {
    ID          string                 `json:"id"`
    Type        EventType              `json:"type"`
    AggregateID string                 `json:"aggregate_id"`
    Data        map[string]interface{} `json:"data"`
    Timestamp   time.Time              `json:"timestamp"`
}

func NewEvent(eventType EventType, aggregateID string, data map[string]interface{}) *Event {
    return &Event{
        ID:          uuid.New().String(),
        Type:        eventType,
        AggregateID: aggregateID,
        Data:        data,
        Timestamp:   time.Now().UTC(),
    }
}

For synchronous communication, we define gRPC contracts. Here’s our proto/order.proto:

syntax = "proto3";

service OrderService {
    rpc CreateOrder(CreateOrderRequest) returns (CreateOrderResponse);
    rpc GetOrder(GetOrderRequest) returns (GetOrderResponse);
}

message CreateOrderRequest {
    string customer_id = 1;
    string product_id = 2;
    int32 quantity = 3;
}

message CreateOrderResponse {
    string order_id = 1;
    OrderStatus status = 2;
}

enum OrderStatus {
    PENDING = 0;
    CONFIRMED = 1;
    CANCELLED = 2;
}

Generate Go bindings with:

protoc --go_out=. --go-grpc_out=. proto/*.proto

Now for the magic: NATS integration. How do we ensure reliable messaging? JetStream provides persistence. Our pkg/nats/client.go handles connections:

package nats

type Client struct {
    conn *nats.Conn
    js   jetstream.JetStream
}

func NewClient(config Config) (*Client, error) {
    nc, err := nats.Connect(config.URL)
    if err != nil {
        return nil, err
    }
    
    js, err := jetstream.New(nc)
    if err != nil {
        return nil, err
    }
    
    return &Client{conn: nc, js: js}, nil
}

func (c *Client) PublishEvent(ctx context.Context, event *events.Event) error {
    data, err := event.ToJSON()
    if err != nil {
        return err
    }
    
    _, err = c.js.Publish(ctx, string(event.Type), data)
    return err
}

func (c *Client) Subscribe(eventType events.EventType, handler func(*events.Event)) error {
    _, err := c.js.Subscribe(string(eventType), func(msg jetstream.Msg) {
        event, err := events.FromJSON(msg.Data())
        if err != nil {
            msg.Nak()
            return
        }
        handler(event)
        msg.Ack()
    })
    return err
}

Notice the message acknowledgment? That’s key for reliable processing. If our handler fails, NATS will redeliver the event. How might we handle poison pills that repeatedly fail?

Here’s a critical insight: Combine gRPC for request/response and NATS for events. When an order is created via gRPC, the Order Service publishes an OrderCreated event. The Payment Service consumes it, processes payment, then emits PaymentProcessed. This choreography continues through inventory checks and notifications.

What happens when services go offline? NATS JetStream persists messages, ensuring no events are lost. We configure retention policies matching our business needs. For payment events, we might keep messages for 7 days, while notifications could use shorter retention.

For deployment, our docker-compose.yml brings everything together:

version: '3.8'

services:
  nats:
    image: nats:latest
    ports:
      - "4222:4222"
    command: "-js"

  order-service:
    build:
      context: .
      dockerfile: cmd/order-service/Dockerfile
    depends_on:
      - nats
      - postgres

  # Additional services...

  postgres:
    image: postgres:14
    environment:
      POSTGRES_PASSWORD: example

We’re just scratching the surface. Imagine adding distributed tracing to track requests across services, or circuit breakers to prevent cascading failures. What patterns would you implement for inventory management during flash sales?

This architecture shines in real-world scenarios. When our payment processor had an outage recently, orders continued flowing through NATS. Once payments came back online, they processed the backlog without manual intervention. That’s the power of decoupled systems!

Now it’s your turn. What challenges have you faced with microservices? Share your experiences below - let’s learn from each other. If this helped you, pass it along to someone who might benefit!