• time-sortable UUID is an ID that contains information about when it was generated, so IDs generated later generally sort after IDs generated earlier.

  • 48 bits: Unix timestamp in milliseconds.
  • 4 bits: UUID version.
  • 2 bits: UUID variant.
  • 74 bits: Remaining bits for randomness and optional monotonicity mechanisms.

• RWMutex instead of plain Mutex?

  • In ‘mu.Lock()/mu.unlock()’ → only one go routine write at a time.
  • Multiple goroutines can read concurrently (mu.RLock() / mu.RUnlock())

  NOTE: reads happesn more than writes

• so basically we create the instance of the STRUCT in main.go and pass it in the handlers as ‘dependency Injection’ —> because of handlers should be create anythign on its own, I will server handlers.

1. Nike registers its URL with Relay using POST /v1/endpoints:

{
  "url": "<https://api.nike.com/webhooks/orders>",
  "event_types": ["order.created"]
}

Relay gives Nike a secret key for signatures.

1. Someone buys sneakers on Shopify. Shopify sends one quick request to Relay and moves on using POST /v1/events:

{
  "type": "order.created",
  "data": {"order_id": 101, "item": "Air Jordan", "price": 150}
}

Relay responds, “202 Accepted! I’ll take care of delivering it.”

1. Relay’s internal engine kicks in. It looks up who wants order.created and finds Nike’s URL. Its background worker signs the payload and sends a POST request to https://api.nike.com/webhooks/orders.
2. If Nike returns 200 OK, Relay logs: SUCCESS (delivered in 45ms).
3. If Nike returns 500 or times out, Relay doesn’t give up. It schedules retries: 5 seconds later, 30 seconds later, then 2 minutes later. If delivery fails five times, Relay moves the event to the dead-letter queue (DLQ). When Nike fixes its server, it can click “Replay” in Relay to retry delivery.