How Bevi Uses InfluxDB to Monitor and Maintain Thousands of Smart Water Coolers

Overview

Building a connected, more sustainable beverage system

Bevi builds internet-connected beverage dispensers that serve customizable still, sparkling, flavored, and enhanced water using filtered tap water. Its mission is to reduce the packaging and transportation required by traditional bottled beverages by filtering water at the point of use and shipping only ingredients such as flavors, CO₂, and filters.

Behind the touchscreen is a distributed IoT system connecting thousands of machines. Every interaction with a Bevi generates data that helps the company understand how its machines are operating and how customers are using them. Dispense events record information such as water type and flavor selections, while newer machines contain dozens of sensors monitoring operating conditions including CO₂ pressure and temperature.

That data supports much more than reporting. Bevi uses it to monitor machine health, calculate inventory and usage, troubleshoot software and hardware issues, alert service teams, and continuously improve how its machines operate in the field.

Challenge

Scaling the data infrastructure behind a growing fleet

Bevi has used InfluxDB since 2014. By 2021, the company was ready to move to InfluxDB 2.0 and modernize an architecture that had been built when its fleet and data volumes were much smaller.

The original architecture wrote machine events synchronously to InfluxDB whenever a Bevi communicated with the backend. As the fleet grew, that meant a large number of small writes hitting the database at once. At the scale Bevi described in 2023, machines were sending approximately 150–200 requests per second containing roughly 2,500 individual events.

That pattern created unnecessary traffic and thread usage on Bevi’s backend and could cause crashes when too much data was sent to InfluxDB at once. Bevi needed a more scalable way to ingest the continuous event stream without slowing down communication between its machines and backend services.

The data itself also presented a challenge. Bevi machines produce flexible JSON key-value events, but the company needed typed data in InfluxDB to make those measurements easy to query, aggregate, and visualize in tools like Grafana. As part of its migration, Bevi created a more disciplined schema while preserving unexpected data rather than simply dropping it.

Enter influxdb

Building a more scalable path from machine to database

Working with the InfluxData team, Bevi redesigned its write architecture around Redpanda, Telegraf, and InfluxDB.

When Bevi’s backend receives an event or batch of events from a machine, it publishes them to Redpanda, a Kafka-compatible data streaming platform. That is the only part of the process that happens synchronously with the machine request, allowing Bevi’s backend to acknowledge the data quickly and continue processing other traffic.

From there, Telegraf subscribes to Redpanda asynchronously. Rather than sending every individual machine request directly to InfluxDB, Telegraf collects events from hundreds of machines into batches containing thousands of events and writes those larger batches to InfluxDB.

InfluxDB then serves as Bevi’s fast, accessible source for the latest information about individual machines. Bevi’s backend queries it for inventory calculations, debugging, usage information, and machine configuration. Grafana connects directly to InfluxDB to give hardware teams real-time visibility into signals such as CO₂ pressure, water temperature, application status, memory use, and available disk space.

RESULTS

Faster response times and more proactive service

Bevi’s updated architecture reduced load and thread usage on its backend, improved response times, and eliminated the crashes it had experienced when too much traffic was sent directly to InfluxDB. By 2023, the system was handling roughly 2,500 events per second from thousands of connected machines, with a path to scale further as the fleet grows.

InfluxDB also gives Bevi’s software and hardware teams a real-time and historical view into machines in the field. Engineers can investigate application status, memory and disk usage, CO₂ pressure, water temperature, heater behavior, and other signals remotely, helping them diagnose problems faster and understand what happened before an issue occurred.

That visibility supports more proactive maintenance. Bevi can alert service teams when a machine detects a leak, goes offline, needs preventive maintenance, or requires a hardware retrofit. If CO₂ or a flavor runs out, Bevi can disable only that option rather than taking the entire machine out of service.

The same telemetry also helps Bevi improve its products and operations over time. Teams can analyze how machines behave in the field and use that data to refine inventory and usage algorithms, troubleshoot hardware behavior, and improve service.

What’s Next

Scaling InfluxDB alongside the fleet

As Bevi’s fleet and data volumes continue to grow, the team is thinking about how its data infrastructure should evolve with it. One area of focus is reducing the operational overhead of managing the underlying service as scale increases.

Data lifecycle is another consideration. Bevi has historical machine data dating back to 2014, but much of the oldest data is rarely accessed. The team has explored a more deliberate approach to retention, keeping frequently used operational data readily accessible while moving older data to lower-cost storage.

For Bevi, the goal is to make sure its data infrastructure can continue to scale alongside the fleet while keeping the information its engineering, hardware, and service teams need close at hand.