I’ve been thinking a lot lately about how we build systems that can handle real-world complexity without collapsing under their own weight. The shift toward event-driven architectures feels less like a trend and more like a necessary evolution—especially when you need systems that are both resilient and responsive. That’s why I want to share a practical approach to building production-ready microservices using NATS, Go, and Kubernetes.

Have you ever wondered how modern applications manage to stay responsive even when individual components fail?

Let me walk you through a real-world implementation. We’ll create a simple e-commerce system with three core services: orders, payments, and inventory. Each service will communicate through events rather than direct API calls, which improves both scalability and fault tolerance.

NATS serves as our messaging backbone. It’s remarkably lightweight and supports multiple patterns, including request-reply and pub/sub. Here’s how we establish a connection in Go:

nc, err := nats.Connect("nats://localhost:4222")
if err != nil {
    log.Fatal("Failed to connect to NATS:", err)
}
defer nc.Close()

But production systems need more than basic connectivity. We implement automatic reconnection and proper error handling:

opts := []nats.Option{
    nats.MaxReconnects(10),
    nats.ReconnectWait(2 * time.Second),
    nats.DisconnectErrHandler(func(nc *nats.Conn, err error) {
        log.Printf("Disconnected: %v", err)
    }),
    nats.ReconnectHandler(func(nc *nats.Conn) {
        log.Println("Reconnected to", nc.ConnectedUrl())
    }),
}

What happens when a service goes down temporarily? Do messages get lost?

JetStream, NATS’ persistence layer, ensures message durability. We configure streams to retain messages even when consumers are offline:

js, err := nc.JetStream()
if err != nil {
    log.Fatal("JetStream error:", err)
}

// Create a stream for order events
_, err = js.AddStream(&nats.StreamConfig{
    Name:     "ORDERS",
    Subjects: []string{"orders.>"},
    MaxAge:   24 * time.Hour,
})

Each microservice includes health checks and graceful shutdown. This allows Kubernetes to manage the lifecycle properly:

func healthCheck(w http.ResponseWriter, r *http.Request) {
    if nc.Status() != nats.CONNECTED {
        w.WriteHeader(http.StatusServiceUnavailable)
        return
    }
    w.WriteHeader(http.StatusOK)
}

func main() {
    // Setup signal handling for graceful shutdown
    ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGINT, syscall.SIGTERM)
    defer stop()

    go func() {
        <-ctx.Done()
        // Cleanup resources
        nc.Drain()
        log.Println("Shutting down gracefully")
    }()
}

How do we ensure that events remain understandable as the system evolves?

We use versioned event schemas from the start. Each event includes metadata that helps with tracing and compatibility:

type Event struct {
    ID            string    `json:"id"`
    Type          string    `json:"type"`
    Source        string    `json:"source"`
    Version       string    `json:"version"`
    Timestamp     time.Time `json:"timestamp"`
    CorrelationID string    `json:"correlation_id"`
    Data          []byte    `json:"data"`
}

Deploying to Kubernetes requires careful configuration. We use readiness probes to ensure services only receive traffic when truly ready:

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 20

Monitoring becomes crucial in distributed systems. We expose metrics that help track message flow and service health:

func setupMetrics() {
    ordersProcessed := prometheus.NewCounterVec(
        prometheus.CounterOpts{
            Name: "orders_processed_total",
            Help: "Total number of orders processed",
        },
        []string{"service", "status"},
    )
    prometheus.MustRegister(ordersProcessed)
}

Building event-driven microservices requires thinking differently about communication and failure. But the payoff is substantial: systems that handle scale gracefully and recover from failures automatically.

What challenges have you faced when moving to event-driven architectures?

I’d love to hear your thoughts and experiences. If you found this useful, please share it with others who might benefit. Feel free to leave comments or questions below!