I'm Louis Low, a Senior Software Engineer and AWS Cloud Practitioner based in Singapore. I lead the geospatial work for Agronomy and Farming Services as the subject matter expert for GEOS, and I'm a Technical Lead in training. To be clear about the rest: the AgriTech platform's architecture is not my design. I work closely with the platform architect on both the designs and the implementations that follow from them, and I put proposals of my own forward where I can see a way to improve the overall system. This page describes the architecture I work in, why it is shaped the way it is, and the part I contribute. The companion geospatial engineering page covers the side I do lead, and the software engineering portfolio collects my earlier projects.
WHAT AGRITECH ASKS OF A PLATFORM
Agronomy and farming services put demands on a system that a typical web application never sees. Data arrives from the field rather than from a form, it arrives late and out of order, and it describes places and seasons as much as it describes records. A few consequences follow from that:
- Everything is located: a field, a boundary, a sample point. Location is part of the record, so the services and APIs carry geometry rather than treating it as an afterthought.
- Everything is seasonal: the same field means different things across a growing season, so history matters and records are rarely just overwritten.
- Work arrives in bursts: load follows the agricultural calendar, not office hours, which is a strong argument for elastic, event-driven services over always-on capacity.
- Connectivity is not a given: anything sourced from the field has to tolerate delay and retry without corrupting the record it belongs to.
THE ARCHITECTURE I WORK IN
These are the platform's patterns. The architecture is the platform architect's to own, and I work through it with them rather than around it. Understanding why each one is there is most of what makes a change to the system safe, and most of what makes a proposal to change one worth listening to:
- Cloud microservices on AWS: services scoped to a domain capability, deployed independently, and sized so a team can own one end to end.
- Request and event-driven together: synchronous REST and GraphQL where a caller needs an answer now, Apache Kafka topics where work should be handed off, replayed or fanned out to several consumers.
- Serverless where the load is spiky: AWS Lambda applications for bursty and scheduled processing, so seasonal peaks cost what they use.
- Caching and read paths: Redis in front of the expensive reads, so map and dashboard views stay responsive while the authoritative data stays in PostgreSQL.
- Service-to-service identity: Auth0 machine-to-machine authentication, so a service proves who it is rather than sharing a secret with everything else on the network.
- Reproducible infrastructure: containers with Docker, orchestration on Kubernetes, and infrastructure described in Terraform so an environment can be rebuilt rather than remembered.
DELIVERY & OPERATIONS
An architecture is only as good as the pipeline that ships it and the instrumentation that tells you what it is doing. I work test-first with TDD and BDD, cover services with Jest across unit and end-to-end suites, and ship through GitHub Actions. In production, Instana and Datadog are how the system explains itself: tracing across service boundaries, metrics and errors with enough context to act on, and logs that can be searched when something looks wrong at three in the morning during harvest.
WHERE I LEAD, AND WHERE I CONTRIBUTE
I lead the geospatial work. The crop biomass and variable rate application maps, the spatial data behind them and the services that deliver them are the part I own and answer for, and as the subject matter expert for GEOS I'm the person the team comes to when a question turns out to be a geospatial one.
Across the wider platform my role is different. I work closely with the platform architect on the designs and on the implementations that come out of them, and where I can see a way to improve the overall system I write the proposal up and argue for it. Some of those land and some don't; either way the architecture stays theirs to own. What I bring to it is the engineering judgement of someone who has to build and operate the result.
I'm also training into the Technical Lead role for Agronomy and Farming Services, which means backing my team's technical growth through mentoring, research and hands-on practice, and working to Scrum and SAFe so that what we plan is what we can deliver, sprint after sprint, for the customers and stakeholders who depend on it.
PLATFORM STACK I WORK WITH
- Amazon Web Services (AWS), AWS Lambda / serverless
- Apache Kafka (event-driven architecture)
- NestJS, Node.js, Python
- REST APIs, GraphQL
- PostgreSQL, Redis
- Auth0 machine-to-machine (M2M) authentication
- Docker, Kubernetes, Terraform
- GitHub Actions
- Jest (TDD / BDD)
- Instana, Datadog
- Angular, React
My current AgriTech work is covered by client confidentiality, so individual systems and clients aren't detailed here, and nothing above describes a specific deployment. If you'd like to talk through the specifics, please get in touch.
Contact me > Geospatial engineering > View Portfolio >