Inquiry: Increasing default result size for Search API and SSE stream overhead for 100+ Things

[radhikais07]

Context: I am working on a Digital Twin project for a building involving ~100+ things. My current pipeline streams AQI data via Sensor → MQTT → Kafka → Eclipse Ditto.

Problem: When fetching the initial state of the city to cache in a Flask backend, the Search API (/api/2/search/things) defaults to a size of 25. While I can use ?limit=100, I am concerned about the performance implications and potential "throttling" when frequently requesting large batches.

Questions for Developers:

Batch Limits: Is there a hard internal limit to the size parameter in the Search API beyond which performance significantly degrades for the search index?

SSE Scaling: For a twin with 100+ things, is the Server-Sent Events (SSE) /things endpoint the recommended way to keep a secondary cache synced, or should I be looking at the Managed Connections (Kafka/MQTT) for outbound synchronization?

Pagination vs. Bulk: For initial state synchronization of 100+ items, is it better to use a single large request or multiple paginated requests using the cursor or Last-Event-ID approach?