IoT sensor data sealed on a permissioned blockchain for the agricultural sector

Summary

An agri-food company needed to immutably seal data generated by IoT sensors deployed across crop fields. The work involved designing and implementing a full stack system that receives the data, processes it asynchronously, seals it on a permissioned blockchain (Alastria, based on Quorum) and exposes it through a simple web visualizer that lets authorized users query records directly from the chain.

Context

The company operated in an environment where traceability of crop data (humidity, temperature, irrigation, treatments, etc.) has regulatory and commercial implications. Data was arriving from IoT sensors in the field and being stored in internal systems, but there was no technical guarantee that the information had not been modified after recording.

The technical environment included Java backend services, containerized infrastructure with Docker and a node on the Alastria network — a Spanish permissioned blockchain based on Quorum (the enterprise variant of Ethereum). The operational constraints were clear: on-chain writes have a different cost and latency than a traditional database, sensors generate a constant stream of events, and any failure in the sealing process could not block the main ingestion flow.

Problem

The system had to meet requirements that were in tension with each other:

Seal relevant readings immutably and verifiably.
Not introduce latency or tight coupling between ingestion and the blockchain.
Tolerate node failures or network congestion without losing events.
Allow authorized users to query sealed data simply, without relying on external technical tools like block explorers.

A naive approach — writing each reading synchronously to the blockchain directly from the ingestion endpoint — was unviable for performance and operational coupling reasons.

Goals

Implement a reliable sealing mechanism, decoupled from the blockchain’s response time.
Guarantee no events are lost during transient failures.
Expose a simple web interface to visualize sealed data directly from the chain.
Keep the solution deployable and reproducible in containerized environments.

Technical approach

The architecture was designed in layers with separated responsibilities: ingestion, async processing, on-chain sealing and visualization.

Ingestion layer. A Java backend service exposed a REST API to receive sensor data. Its responsibility was to validate, persist the event and publish it to a RabbitMQ queue. This decoupled ingestion from the sealing process and allowed absorbing traffic spikes without putting pressure on the blockchain.

Processing layer. A dedicated worker consumed messages from RabbitMQ, normalized the data and prepared the transaction to be sent to the chain. Using a queue allowed applying retries, backoff and isolating failures without affecting the ingestion endpoint.

On-chain sealing layer. A Web3 service in Java (Web3j) interacted with the Alastria/Quorum node through a smart contract that recorded the relevant data for each reading. The contract was kept deliberately simple: the less logic lives on-chain, the cheaper and safer it is to evolve over time.

Visualization layer. A React web interface, simple and business-user oriented, was developed to query the blockchain directly (through a Web3 endpoint) and display sealed records. The idea was that any authorized party could see the data exactly as it exists on the chain, without going through an intermediate database that would break the chain of trust. The UI focused on the essentials: reading list, search by sensor or time range and a detail view with on-chain information.

The entire system was packaged as independent Docker containers (ingestion API, worker, Web3 service, RabbitMQ, database, frontend), making deployment, horizontal scaling and fault isolation straightforward.

Additional measures included:

Retries with backoff in the sealing layer to tolerate temporary node failures.
Idempotency in the worker to prevent duplicates from message redelivery.
Structured logs to audit the pipeline in production.

Decisions and trade-offs

The first key decision was decoupling ingestion from sealing using queues. This introduces a small window between the event and its on-chain registration, but in return the system survives blockchain node failures without losing data or blocking the main flow.

The second was keeping the contract as simple as possible. Business logic was deliberately kept out of the smart contract; the more logic lives on-chain, the more expensive and risky its evolution becomes. Relevant logic stayed in the backend, where it can be iterated without costly migrations.

The third was having the visualizer read directly from the chain rather than a mirror database. This aligned with the project’s purpose: if the differentiating value is immutability, the UI should reflect the real source of truth. In return, some read latency and node dependency were accepted, mitigated with light caching in the frontend.

Result

Functional pipeline capable of stably processing the IoT event stream and sealing it on the permissioned blockchain without coupling ingestion to the node.
Tolerance to Quorum node failures without event loss thanks to queue-based decoupling.
Simple, usable web visualizer allowing authorized users to query data directly from the chain, maintaining end-to-end traceability.
Reproducible, Docker-deployable infrastructure.

Tech stack

Java
Web3j
Quorum / Alastria (permissioned blockchain)
Solidity (smart contract)
RabbitMQ
React
Docker
REST APIs

What this case demonstrates

This case demonstrates the ability to design distributed systems combining heterogeneous technologies — IoT, messaging, blockchain and frontend — while maintaining clear separation of responsibilities, fault tolerance and a user experience aligned with the system’s purpose. It also reflects judgment about what should go on-chain and what shouldn’t, and how to align technical decisions (including the visualizer’s data source) with the project’s real value.

Building something that requires tamper-proof data traceability? I can help you design the architecture and decide where blockchain actually adds value versus where simpler solutions are a better fit.