DEV Community: Toluwanimi Alfred

Building a Serverless Agriculture Platform with AWS

Toluwanimi Alfred — Wed, 02 Sep 2026 03:21:05 +0000

While building HarvestIQ, I started paying much more attention to how backend architecture affects the way a product can be built, deployed, and scaled.

HarvestIQ is an agriculture platform designed to help smallholder farmers access post-harvest intelligence, including market prices and buyer opportunities.

One of the interesting parts of the project is that a farmer can interact with the system through USSD, without requiring a smartphone or an internet connection.

The backend is built around a serverless architecture using AWS services.

This article breaks down how that architecture works and what I have learned from building it.

What does "serverless" actually mean?

The name can be misleading.

Serverless does not mean that there are no servers.

The servers still exist. AWS manages the underlying infrastructure, while I focus on writing and deploying the application code.

Instead of maintaining an always-running backend server, different parts of the application can run when they are needed.

For HarvestIQ, this works particularly well because many operations are event-driven.

A farmer makes a request.

A function executes.

Data is retrieved or updated.

The function finishes.

Another event can trigger another function later.

HarvestIQ's Serverless Architecture

The simplified architecture looks like this:

                    Farmer
                      |
                     USSD
                      |
                      v
              Africa's Talking
                      |
                      v
                AWS Lambda
                 /       \
                /         \
               v           v
          DynamoDB       Response


          EventBridge
               |
               v
          AWS Lambda
               |
               v
          Price / Alert
            Logic
               |
               v
             SNS
               |
               v
              SMS
               |
               v
             Farmer

Each AWS service has a specific responsibility.

AWS Lambda handles application logic.
DynamoDB stores application data.
EventBridge triggers scheduled operations.
SNS handles notifications.
Africa's Talking provides the USSD and SMS connectivity layer.

Let's look at each part.

1. USSD as the Entry Point

One of the design goals of HarvestIQ is accessibility.

A farmer should not necessarily need:

A smartphone
A mobile application
Mobile data
A web browser

A basic mobile phone with cellular connectivity can be enough.

The farmer interacts with HarvestIQ through a USSD menu.

For example:

HarvestIQ

1. Check Market Price
2. List Produce
3. View Buyer Demand
4. Set Price Alert

The USSD request is handled through the Africa's Talking USSD gateway and passed to the backend.

This is where AWS Lambda comes in.

2. AWS Lambda

AWS Lambda is the compute layer of the application.

Instead of maintaining a traditional server that is continuously running, I can deploy functions that execute in response to events.

The basic idea is:

Event
  |
  v
Lambda Function
  |
  v
Execute Code
  |
  v
Return Result

For example, when a farmer sends a USSD request:

Farmer
   |
   v
USSD Request
   |
   v
AWS Lambda
   |
   v
Process Request
   |
   v
Return USSD Response

The Lambda function can also communicate with other AWS services.

For example:

Lambda
   |
   +----> DynamoDB
   |
   +----> SNS

This means the application logic does not have to live on one large traditional backend server.

3. DynamoDB

HarvestIQ uses Amazon DynamoDB as its database.

This is where application data can be stored and retrieved by Lambda functions.

For example, the system can store information related to:

Farmers
Produce listings
Market prices
Buyer demands
Price alerts

A simplified interaction might look like this:

USSD Request
     |
     v
Lambda
     |
     v
DynamoDB
     |
     v
Retrieve Data
     |
     v
Lambda
     |
     v
USSD Response

For example, when a farmer requests the current price of maize, Lambda can query DynamoDB and return the relevant information through the USSD session.

4. EventBridge for Scheduled Jobs

Not everything in HarvestIQ starts with a farmer.

Some operations need to happen automatically.

For example, market prices may need to be updated periodically.

This is where Amazon EventBridge becomes useful.

Instead of keeping a server running and writing a program that constantly waits for the next scheduled operation, EventBridge can trigger a Lambda function according to a schedule.

Conceptually:

EventBridge
     |
     | Scheduled Event
     v
Lambda
     |
     v
Run Price Update
     |
     v
DynamoDB

For example:

8:00 AM  -> Lambda runs
10:00 AM -> Lambda runs
12:00 PM -> Lambda runs
2:00 PM  -> Lambda runs

The exact schedule depends on the application requirements.

This is one of the things I found interesting about event-driven architecture: the system does not need to continuously run code just to wait for something to happen.

5. Understanding Amazon SNS

This was one of the concepts I found particularly interesting.

Amazon SNS (Simple Notification Service) is a publish/subscribe messaging service.

A simple way to think about SNS is as a notification or broadcast layer.

Instead of having every part of the application know exactly how to deliver a notification, an application can publish a message to an SNS topic.

Conceptually:

Application
     |
     v
SNS Topic
   /   \
  /     \
SMS     Other Subscribers

In HarvestIQ, this can be useful for price alerts.

Suppose a farmer sets a target price:

Produce: Maize
Target Price: ₦85,000

Later, the system checks the current market price.

If the target condition is satisfied, the application can publish a notification through SNS.

The flow becomes:

EventBridge
     |
     v
Price-check Lambda
     |
     v
DynamoDB
     |
     v
Target condition reached
     |
     v
Lambda publishes notification
     |
     v
SNS
     |
     v
SMS notification
     |
     v
Farmer

The important distinction is that SNS is not the component deciding whether the target price has been reached.

The application logic does that.

Lambda determines that the condition has been satisfied, then publishes the notification to SNS.

SNS handles the notification delivery to its configured subscriber.

That separation of responsibilities makes the architecture easier to reason about.

A Complete Example

Let's put everything together.

Imagine a farmer wants to know the current price of maize.

Step 1: The farmer sends a USSD request

Farmer
   |
   v
USSD

Step 2: The request reaches the backend

USSD
   |
   v
Africa's Talking
   |
   v
AWS Lambda

Step 3: Lambda retrieves the data

Lambda
   |
   v
DynamoDB

DynamoDB returns the relevant market information.

Step 4: Lambda generates the response

DynamoDB
   |
   v
Lambda
   |
   v
USSD Response
   |
   v
Farmer

The entire interaction can happen without the farmer installing an application or using mobile data.

Now consider a different scenario: a scheduled price update.

EventBridge
     |
     v
Lambda
     |
     v
Fetch / Process Price Data
     |
     v
DynamoDB

And if a price alert condition is reached:

Price-check Lambda
       |
       v
Target reached
       |
       v
SNS
       |
       v
SMS
       |
       v
Farmer

This is the part of the architecture that makes the system event-driven.

Why Use Serverless?

There are several reasons this architecture made sense for HarvestIQ.

1. Less infrastructure management

I don't have to maintain an always-running application server myself.

AWS manages much of the underlying infrastructure.

2. Event-driven execution

Different parts of the application can execute in response to specific events.

For example:

USSD request
     ↓
Lambda

or:

Scheduled event
     ↓
Lambda

or:

Business condition
     ↓
Notification

3. Automatic scaling

Lambda can handle multiple invocations without me manually provisioning individual servers for each request.

The underlying infrastructure is managed by AWS.

4. Efficient use of compute

For workloads that are intermittent or event-driven, there is less reason to maintain an application server that is continuously running just waiting for requests.

Serverless Is Not Perfect

Serverless is not automatically the best architecture for every application.

There are trade-offs.

Cold Starts

A function that has not been invoked recently may experience additional startup latency depending on the runtime and configuration.

For some applications, that latency matters.

Execution Limits

Lambda functions are designed for bounded workloads rather than indefinitely running processes.

That means some workloads are better suited to other architectures.

Distributed Debugging

A traditional application might look like:

Client
  |
  v
Backend
  |
  v
Database

A serverless application can involve many managed services:

USSD
  |
  v
Gateway
  |
  v
Lambda
  |
  +----> DynamoDB
  |
  +----> SNS
  |
  +----> Other Services

EventBridge
  |
  v
Lambda

When something fails, understanding exactly where the failure occurred can require proper logging, monitoring, and tracing.

Vendor Lock-in

Using managed services deeply can also make an application more dependent on a particular cloud provider.

That is an architectural decision worth considering before building at scale.

What I Learned

Building HarvestIQ changed how I think about backend architecture.

The biggest lesson for me is that serverless is less about "not having servers" and more about changing who manages the infrastructure and how application components are executed.

I also learned to think in terms of events.

Instead of asking:

"What server should always be running?"

I started asking:

"What event should cause this piece of code to run?"

For HarvestIQ, those events can be:

Farmer makes a USSD request
              ↓
        Lambda executes

Scheduled update occurs
              ↓
        Lambda executes

Price condition is reached
              ↓
      Notification is published

That shift in thinking is probably the most valuable thing I have taken from building the project.

Conclusion

HarvestIQ started as an attempt to solve a real agricultural problem, but building it has also become an opportunity for me to learn more about cloud architecture and distributed systems.

The combination of Lambda, DynamoDB, EventBridge, and SNS gives the platform a relatively lightweight event-driven backend while allowing me to focus more on the application itself rather than server management.

I'm still learning, and there are several areas I want to explore further, particularly observability, security, cost optimization, and designing more robust distributed systems.

For me, this is one of the interesting parts of building software: the project solves one problem while teaching you how to solve the next one better.

Why the Power-of-Two Trick Works for Binary Fractions (And Why It Breaks for Everything Else)

Toluwanimi Alfred — Thu, 18 Jun 2026 12:25:50 +0000

If you've taken any course that covers number systems, you've probably learned the "repeated multiplication" method for converting a decimal fraction to binary. Multiply by 2, record the digit before the decimal point, keep the remainder, repeat. It works. You can pass an exam with it. But it also feels a little like a magic trick — you follow the steps, you get the right answer, and you have no real intuition for why it works or why it sometimes never ends.

Here's the thought process that gave me that intuition, and where it eventually breaks.

The starting point: 0.25

Take 0.25. The standard method says: multiply by 2 repeatedly, record the integer parts.

0.25 × 2 = 0.50 → record 0
0.50 × 2 = 1.00 → record 1

Read top to bottom: 0.25 = 0.01 in binary. Correct, but mechanical.

Here's the alternative way I started thinking about it instead. 0.25 is just 1/4. And 4 is 2². So instead of multiplying repeatedly, what if I convert the numerator and denominator to binary separately, and treat the division as what it actually is — a division by a power of the base?

1 in binary is 1.
4 in binary is 100.

So 1/4 is 1 / 100 in binary. And dividing by 100 (in any base) doesn't require long division if 100 is a power of that base — it just shifts the point. In decimal, dividing by 100 shifts a decimal point two places left because 100 is 10². In binary, dividing by 100₂ (which is 4 in decimal) shifts the binary point two places left for exactly the same reason: 100₂ is 2².

Shift the point in "1." two places left: 0.01₂.

Same answer, but now you can see why it's the answer instead of just trusting the algorithm.

This isn't a coincidence — it's how place-value systems work

This generalizes. Any fraction a/2ⁿ can be converted by writing 'a' in binary and shifting the point n places. 1/2 → shift 1 place → 0.1₂. 1/8 → shift 3 places → 0.001₂. 3/16 → 3 is 11 in binary, shift 4 places → 0.0011₂.

It's the same logic as why dividing by 1000 in decimal is "free" (just move the point three places) — except in binary, the powers that are "free" are powers of 2, not powers of 10. This is also, not coincidentally, the entire basis of fixed-point arithmetic in embedded systems: when a microcontroller needs to represent a fraction without the overhead of a floating-point unit, it represents the value as an integer with an implicit binary point at a fixed position, and operations that would otherwise need division become bit-shifts. The "trick" above is a small, hand-worked version of that same idea.

Where it breaks

The shortcut depends entirely on the denominator being a power of 2. Try it on 0.2, which as a fraction is 1/5.

5 in binary is 101. 101 is not a power of 2 (it's 4 + 1, not a single power), so there's no clean shift available. To get 1/101₂ you actually have to do binary long division, and unlike 1/4, this one doesn't terminate. It repeats forever: 0.0011001100110011...

This is the same underlying reason 0.1 + 0.2 doesn't exactly equal 0.3 in most programming languages — 0.1 and 0.2 are not exactly representable in binary floating point, because their denominators (10 and 5) aren't powers of 2. It's not a bug in your code; it's a structural consequence of representing base-10 fractions in a base-2 system.

So the boundary is sharp: this shortcut is fast and exact for denominators of 2, 4, 8, 16, 32, and so on (equivalently, decimals like 0.5, 0.25, 0.125, 0.0625, 0.375). For anything else, you're back to repeated multiplication, and the result may never terminate.

The takeaway

None of this is a new method — it's a restatement of how positional number systems and fixed-point representation work, just arrived at by asking "what is this algorithm actually doing" instead of memorizing the steps. But that's worth writing down, because most people learn the multiplication method as a rote procedure and never connect it to the much more general (and much more useful) fact: in any base, dividing by a power of that base is just a point shift, and that single fact is also why certain "simple" decimal fractions can never be represented exactly in binary — a fact that quietly underlies one of the most common gotchas in floating-point programming.