How do you keep thousands of cattle safely within virtual fences, in real time, across sprawling farms? For Halter, the answer runs on Amazon DynamoDB. Read the full story. 👉 https://go.aws/46YTX6G Halter is a New Zealand based agricultural technology company using smart, solar-powered collars to revolutionize how farmers manage their herds. Behind every virtual fence, GPS ping, & animal-welfare check is an AWS backend built to scale. A look under the hood: • An event-driven microservices architecture with 80+ components, backed by 300+ Amazon DynamoDB tables • A single virtual-fence command can fan out to hundreds of collars at once — each sending back its own acknowledgment. DynamoDB's partition-based design absorbs those write spikes with no manual intervention • A mix of provisioned capacity (for predictable, high-traffic collar telemetry) & on-demand capacity (for new internal tools starting small & growing fast) to balance performance & cost • Amazon ElastiCache for Valkey as a read-through cache, delivering near-real-time animal locations to farmers over WebSockets with sub-millisecond latency — without adding load to DynamoDB "Amazon DynamoDB is a key part of Halter's ability to uphold animal welfare standards at scale due to its reliability." — Antony Southworth, Lead Data Engineer, Halter
Antony Southworth thanks for the collaboration here!
Data & AI Engineer | AWS | Data Lakehouse & Data Mesh | AI Agents | ETL & Analytics | 20+ Years in Financial Technology
2wTechnically, it all looks very impressive, but I think there’s another important question: are we seeing the best solution, or simply a solution that makes extensive use of cloud services? 300+ DynamoDB tables, 80+ components, Kinesis, Lambda, ElastiCache, Firehose, S3, ML, WebSockets… It certainly demonstrates scalability, but it also introduces a significant amount of complexity and cost. Could the same problem have been solved with a much simpler architecture and a different strategy? Absolutely possible. Without knowing the actual traffic patterns, cost per collar, operational overhead, and the alternatives that were evaluated, it’s difficult to tell. Sometimes, in cloud architecture, we end up showcasing how many services we can use, rather than demonstrating how simply and efficiently we can solve the problem. Technical scalability is impressive, but simplicity, cost, and operational efficiency should be part of the story too.