Skip to content
Events Service

Quality of service

Throughput

  • Publishers are able to publish to a topic at a rate of 500 transactions per second (with a max of 10 messages batched within each transaction). If this limit is exceeded, your application will be throttled for 5 seconds as described in the Throttling Publish Requests page.

  • Consumers are able to poll at a rate of 100 transactions per second (up to 1000 messages per second, when receiving 10 events per poll). If this limit is exceeded, your application will be throttled for 45 seconds as described on the Throttling events consumption page.

Latency

  • 99 percentile of end-end time is 253 milliseconds.

Uptime

  • The Event Service generally sees a monthly average up time of 99.999%.

  • However, the service can only commit to the aggregate uptime of the underlying services we use. We calculate this by multiplying the uptime of all the underlying services together:

    • ENS uptime = MSK * ECS * EC2 * RDS * ALB
    • ENS uptime 99.9% * 99.5% * 99.99% * 99.95% * 99.99% = 99.33%

  • You can find the current status and uptime stats of the service on the Status Page{:target=“_blank”}.

Scalability

  • The underlying system is built on Kafka and is architected to scale in a similar manner as Kafka.
  • Comprehensive performance testing has been executed, and detailed test results can be found here{:target=“_blank”}.

Event Retention

  • Events are stored for a duration of 30 days from the date and time of publication.
  • To avoid message loss, consumers should process messages within this period. Events not consumed within the retention window will be discarded.

Message ordering

  • Message order is only preserved when the publisher includes an entity id and when the consumer polls using a single instance. The entity id is internal to the Events Service, reach out to the team (DispatchRider-ug@trimble.com{:target=“_blank”}) if you’d like to know whether or not a certain event topic does maintain event order.
  • Consumers must use the SDK and poll using only a single consumer group for order to be maintained.

We are actively determining alternative methods to preserve message order when multiple consumer instances are used.

Acknowledgement

Consumers can acknowledge messages once successfully processed to ensure message integrity and prevent loss. This is further described on the Acknowledgement page.