Check the username and password. Both values are case-sensitive. Also, confirm that you are using the credentials for the correct environment, and that the SASL mechanism matches the one provided by Upvest.
Confirm the bootstrap server hostname and port match what Upvest provided, and that your network allows outbound TCP to the broker. Check any corporate firewall rules.
Verify the topic name matches exactly, as names are case-sensitive. If a topic should be accessible but is not, contact your Upvest representative.
No custom certificate is required on your side. Make sure your runtime's system CA bundle is up to date, and never disable TLS verification in production.
Whether this is expected depends on your topic's partition key — see Partitioning to confirm which one applies to your topic.
- Tenant keying: all your events are on a single partition, so Kafka guarantees order across your entire stream. Out-of-order events are not expected from Kafka itself — check whether your consumer processes messages concurrently in a way that can reorder them.
- User or entity keying: only events sharing the same key are ordered relative to each other. Events under different keys can land on different partitions and interleave — this is expected, not a fault.
Kafka assigns each partition to exactly one consumer instance within a group. If you run more instances than your topic has partitions, the extra instances will not receive any events — this is expected, not a fault. If one instance lags while others sit idle, check whether a single partition (and the key driving it) is carrying disproportionate traffic.
If the offset on one partition stops moving while your consumer lag grows, your application is likely retrying the same event. See Handling failed events.
For access requests, credential issues, or integration questions, contact your Upvest representative or your agreed support channel.