Halter Limited powers its high-growth global livestock platform using AWS

Halter’s system combines hardware, software, and AI to manage livestock at scale. Solar-powered GPS collars track cattle’s location and behavior. Using the Halter application, farmers and ranchers can monitor animals in NRT while defining digital boundaries and scheduling herd movements. The collars guide cattle by transmitting audio and vibration cues, reducing the need for physical fencing.

Halter receives a constant stream of telemetry data from its smart collars. On average, the company supports over 6,900 read and 6,700 write requests per second, so it needs an architecture that can ingest, store, and serve data with low latency and high durability.

To store device data that collars stream, Halter uses Amazon DynamoDB, a serverless, fully managed, distributed NoSQL database with single-digit millisecond performance at virtually any scale. This way, the company can handle large volumes of data while maintaining consistent performance as demand grows. Halter’s backend follows an event-driven microservices architecture with over 80 components that are responsible for distinct business domains and backed by over 300 Amazon DynamoDB tables. “Amazon DynamoDB is a key part of Halter's ability to uphold animal welfare standards at scale due to its reliability,” says Antony Southworth, lead data engineer at Halter.

When a farmer draws a virtual-fence polygon in the Halter application, the request flows to a domain service that records the boundary, determines which collars should receive the command, and publishes an event. A separate service translates that event into a command, which is synced to on-farm radio towers over LoRa and delivered to the collars. Acknowledgments flow back through the same pipeline and are persisted in Amazon DynamoDB so that Halter can confirm that every device receives and applies the instructions.

This event-driven pattern means that individual services can scale independently. A single virtual-fence command might fan out to hundreds of collars simultaneously, each requiring its own acknowledgment record. Halter relies on the partition-based architecture of Amazon DynamoDB to absorb those write spikes without manual intervention. With the right primary-key and sort-key design, performance remains consistent regardless of table size. When its access patterns evolve, the company uses global secondary indexes to support new query paths without migrating data.

Halter’s teams can quickly deploy new Amazon DynamoDB tables and scale capacity as application usage evolves, provisioning additional throughput to handle highly critical workloads. The company uses a mix of Amazon DynamoDB capacity modes to suit different workloads. For high-traffic, predictable workloads such as collar telemetry ingestion, the company uses provisioned capacity with reserved pricing to control costs. For internal tools and newer applications where traffic patterns are still emerging, Halter uses on-demand capacity so that the team doesn’t need to predict the right throughput before the application has stabilized.

This flexibility is important because when Halter builds a new internal application, such as a fleet management dashboard or a firmware update tracker, it might start with a single user and grow to hundreds. Through Amazon DynamoDB serverless scaling, the company can avoid the noisy-neighbor issue, which occurs when multiple early-stage applications share a single relational-database instance. Because Amazon DynamoDB is fully managed, the company doesn’t need to handle infrastructure tasks such as partitioning, replication, or failover.

Using Amazon ElastiCache for Valkey—a fully managed, high-performance, and cost-effective in-memory caching solution—Halter improves backend response time and reduces the load on the primary persistence layer. Because of its high-throughput access patterns, Amazon ElastiCache serves as a read-through cache in front of Amazon DynamoDB.

For example, the mobile app displays NRT location data for every animal on a farm. GPS coordinates flow through the ingestion pipeline: from the collar, over LoRa to on-farm towers, through Amazon Kinesis Data Streams to stream data, and into the backend services. Meanwhile, the latest position for each animal is written to Amazon ElastiCache. The connected clients receive updates over WebSockets with submillisecond read latency, without adding load to Amazon DynamoDB.

Halter also uses Amazon ElastiCache to reduce latency for device registry lookups. The core table that records every collar in the fleet (its identity, status, and farm association) is one of the most frequently queried datasets in the system. Caching these reads in Amazon ElastiCache frees Amazon DynamoDB capacity for write-heavy workloads such as telemetry ingestion and command acknowledgments.

Using AWS managed services, Halter reduces operational overhead and helps engineers focus on application development instead of infrastructure maintenance. The company can connect and act on all its data, access a comprehensive set of data and AI capabilities, and manage governance throughout the data workflow. This gives Halter both the confidence to build and quickly launch applications and the space to focus on solving business issues.

Halter’s architecture on AWS can scale efficiently to support more than 1.5 million smart collars and growing demand across New Zealand, Australia, and the United States. Over the decade since its founding, Halter has reduced cost-to-serve per collar by nearly 90 percent. This helps the company enter price-sensitive markets where the cost of labor is low and technology adoption must deliver a clear return.

Reducing costs required sustained effort across the entire stack, but the pricing model of Amazon DynamoDB was central to the strategy. As Halter grew, it shifted high-traffic tables from on-demand to provisioned capacity with reserved pricing. The company also optimized read and write patterns to minimize consumed capacity units and benefited from AWS price reductions for Amazon DynamoDB on-demand mode. By tuning capacity modes to match each workload’s traffic profile, Halter avoided paying for idle throughput while still handling peak collar-reporting windows.