Aviarai

Aviarai is a farm management platform for poultry farmers, helping owners track daily flock performance, manage feed and inventory, monitor health events, and access AI-powered recommendations to reduce waste and improve yield. I joined pre-launch as the backend engineer, responsible for the core platform API from schema through to production.

The stack is Spring Boot and PostgreSQL, deployed as a single service with a companion vaccination microservice. The frontend is a React SPA. I work across both.

The inventory system accepts writes from multiple sources simultaneously: daily entries, dispatches, adjustments, and automated rollups, all potentially hitting the same feed stock records at once. The naive approach of reading current stock, computing a delta, then writing it back is a textbook race condition: two concurrent writes read the same starting value, each calculates independently, and one silently overwrites the other.

The solution moves the arithmetic into the write itself, operating on the stored value directly rather than relying on a read-modify-write cycle. The system also derives reorder status (whether a feed type is low, critical, or healthy) from live stock against configurable thresholds, so the dashboard always reflects current state without a separate status-management layer.

A single user can manage multiple farms on Aviarai, and each farm has staff with different levels of access. The permission model has to answer two questions: does this user have permission for this action in general, and does the resource they're touching belong to the farm they're currently operating under?

The system uses four roles (Admin, Manager, Attendant, Guest) across a feature-level permission matrix. Authorization is enforced at the method level: every protected endpoint checks both role permission and resource ownership before proceeding. Role assignments are farm-scoped, so a user can be an Admin on one farm and an Attendant on another, and context switches cleanly between them.

The frontend mirrors the same permission set in real time. Routes, navigation items, and action buttons all render conditionally based on what the active farm role allows.

The AI feed recommendation feature suggests optimal quantities based on flock age, historical intake, bird weight data, and egg production performance. Before any ML call happens, the system checks eligibility: the flock needs to meet minimum age and laying status criteria, and have a sufficient window of clean daily records. Running recommendations on sparse data produces bad advice, which destroys trust faster than having no AI at all.

When eligible, the system assembles time-series data and calls three separate model endpoints (weight forecasting, intake projection, and energy calculation), then stitches the results into a single recommendation with cost context from live inventory prices. There's also an audit path that can reproduce the same output from a client-supplied snapshot, without hitting the database, for offline reconciliation and dispute resolution.

Farm operations run on schedules: vaccination windows, biosecurity checks, feed reorders. I built a task system where tasks are generated and completed automatically based on two trigger types. Scheduled triggers run nightly on a cron. Cross-module triggers fire when a daily record entry completes or activates a downstream task automatically.

The vaccination logic lives in a companion microservice that expands vaccination programs into dated instances across a rolling time window. When daily records arrive, the service scores them against scheduled instances and auto-completes matching tasks on the main service. Program changes propagate asynchronously, so task states stay in sync without blocking the write path.