QCon London 2025 — UUID v7 in Microservice Architectures

London, United Kingdom · March 24–28, 2025

QCon London 2025 was held March 24–28, 2025. One of the longest-running practitioner-focused software conferences, QCon London draws senior engineers and architects from organisations building large-scale distributed systems.

Identifiers as Architectural Decisions

A recurring theme across QCon London 2025 tracks was that identifier choice is an architectural decision, not a implementation detail. Speakers from multiple organisations described how switching from UUID v4 to UUID v7 for event and entity IDs simplified downstream logic:

Saga Pattern and UUID v7 Correlation IDs

A detailed session on the Saga pattern showed how UUID v7 correlation IDs tie together compensating transactions:

POST /orders              → saga_id: 018fbe3a-4c5d-7000-8abc-000000000001
  → inventory.reserve     → saga_id: 018fbe3a-4c5d-7000-8abc-000000000001
  → payment.charge        → saga_id: 018fbe3a-4c5d-7000-8abc-000000000001
  → notification.send     → saga_id: 018fbe3a-4c5d-7000-8abc-000000000001

When payment fails and the saga must roll back, the saga_id links every compensating transaction. Because it is a UUID v7, log aggregators can reconstruct the full saga timeline by sorting all log entries with that saga_id — no join with a timestamp column needed.

Event Sourcing and UUID v7 Event IDs

Event sourcing sessions covered using UUID v7 as the event ID in append-only event stores:

{
  "event_id": "018fbe3a-4c5d-7b12-8abc-0123456789ab",
  "aggregate_id": "550e8400-e29b-41d4-a716-446655440000",
  "type": "OrderPlaced",
  "payload": { "total": 9900 }
}

Storing events sorted by event_id gives a chronological event log with no additional sort key. Projections that replay events iterate rows by primary key and naturally process them in creation order — a significant simplification over maintaining a separate sequence number column.

Speakers noted that EventStore and Axon Server can accept UUID v7 event IDs directly, with the timestamp improving their internal indexing.

API Gateway Correlation IDs

Talks on API gateway patterns demonstrated propagating UUID v7 as the X-Request-ID header at the gateway level:

# Kong gateway plugin config
plugins:
  - name: correlation-id
    config:
      header_name: X-Request-ID
      generator: uuid  # replace with uuid-v7 custom generator
      echo_downstream: true

Because the gateway stamps every request with a UUID v7 at ingress, all downstream logs share the same correlation ID, which sorts chronologically in any log aggregation tool. Operations teams can query “all requests in the last 5 minutes” using an ID prefix range rather than a timestamp range.

Frequently asked questions

How does UUID v7 help with microservice event ordering?

UUID v7's millisecond timestamp prefix enables approximate cross-service event ordering without a central sequence counter. In the Saga pattern, a saga_id that is a UUID v7 lets log aggregators sort all related events chronologically by ID alone — no join with a created_at column needed. QCon London 2025 included dedicated sessions on this pattern for event-driven architectures.

Can UUID v7 replace a central sequence counter in distributed systems?

For most use cases, yes. UUID v7's millisecond timestamp gives approximate cross-node ordering without any coordination. Each node generates independently, and UUIDs sort in creation order to millisecond precision. For strict global ordering you still need clock synchronisation or a coordination layer — but UUID v7 handles the 99% case where millisecond-level ordering is sufficient.

Should I use v4 or v7?

Use v7 for database primary keys (time-sortable, index-friendly) and v4 for anything where creation order could leak information, like tokens or share links.

How does UUID v7 help in event-driven microservice architectures?

UUID v7's millisecond timestamp prefix enables approximate event ordering without a central sequence service. In event-driven systems, consumers can sort incoming events by their UUID v7 event ID to reconstruct approximate creation order — useful for idempotency checks, deduplication, and replay. The RFC 9562 monotonic counter recommendation further tightens ordering within each producer node.

Can UUID v7 replace a Kafka partition key for ordering?

No. Kafka ordering guarantees are per-partition, not per-key sort order. UUID v7 as a message key does not give you Kafka ordering — Kafka consumers receive messages in the order they were produced to a partition, regardless of the key value. UUID v7 is useful as a correlation ID or event ID within messages, where consumers sort events by the ID after aggregating them. See the Kafka documentation on data flow for partition ordering semantics.