Your company has an application running on Google Cloud that is collecting data from thousands of physical devices that are globally distributed. Data is published to Pub/Sub and streamed in real time into an SSD Cloud Bigtable cluster via a Dataflow pipeline. The operations team informs you that your Cloud Bigtable cluster has a hotspot, and queries are taking longer than expected. You need to resolve the problem and prevent it from happening in the future. What should you do?

A hotspot in Cloud Bigtable indicates that a disproportionate amount of read/write traffic is directed to a small number of nodes, often due to an inefficient row key design. Reviewing the RowKey strategy and ensuring keys are evenly spread across the alphabet (or hash-prefixed) is crucial. This distributes the workload across all nodes, preventing hotspots and improving query performance. Using HBase APIs instead of NodeJS APIs is irrelevant to hotspotting; the API choice doesn't dictate data distribution. Deleting old records might reduce storage but won't resolve a hotspot caused by uneven key distribution. Doubling the number of nodes might temporarily alleviate symptoms by increasing capacity, but it doesn't address the root cause of the uneven distribution and will likely lead to future hotspots and increased costs if the RowKey strategy remains poor.