Engineering reference: the cold chain monitor architecture

The system, by service name

• Compute
• Database
• Networking
• People

Region and account

• Region: us-east-1. Chosen because SES inbound receipt rules exist in only a subset of regions and this one has the widest Bedrock model availability. If your data has to stay elsewhere, check both constraints before moving: inbound SES is the binding one.
• Account: one. This is a small system, and a separate account per environment costs more in wiring than it saves. A dev and a prod stack in the same account, with distinct resource prefixes, is the right size here.
• Everything is regional. The only global resources are the IAM roles and policies. There is no CloudFront, no global table and no cross-region replication, because nothing here has a latency or durability requirement that would justify them.

Lambda inventory

Splitting this into separate functions is not about modularity. It is that only one of them needs Bedrock permissions and only one is reachable from the public internet, and neither of those is true if it is one handler behind a router.

IAM, scoped

No role has a Resource: “*” on anything that writes, and every GetSecretValue grant names a single secret arn. That is why there is more than one secret rather than one JSON blob with everything in it.

DynamoDB schemas

Table: readings

PK   sensor_id         S
SK   taken_at          S   the sensor’s own clock
     received_at       S   when it reached us; often differs
     celsius           N   null on a gap record
     kind              S   reading | gap | implausible | correction
     battery_pct       N
     rssi              N
     note              S   set on correction records only, with a name

No update path exists in any role. A correction is a new item of kind
`correction` referencing the original, and both appear on every chart.

Table: events

PK   unit_id           S   walkin_2
SK   opened_at         S
     kind              S   excursion | breach | gap_breach | sensor_stuck
                           | drift_suspected | calibration_due
     closed_at         S
     peak_celsius      N
     minutes_out       N   consecutive
     cumulative_today  N   minutes, for the review rule
     acknowledged_by   S   a named person, and when
     decision          S   dispose | release | testing
     decided_by        S   a named person
     reason            S   free text, in their words

A release is recorded as carefully as a disposal. The asymmetry in how
carefully those two get written down is where problems hide.

Inbound and outbound

• Sensors report every five minutes over IoT Core. Devices that buffer during signal loss send batches, which is why both timestamps are stored.
• The judge sweeps every sensor every five minutes rather than reacting to arrivals, because the whole point is to notice what did not arrive.
• Unit rules are configuration — range, consecutive limit, cumulative limit — owned by whoever is responsible for the stock, not by the code.
• Escalation runs until acknowledged. There is no maximum number of attempts and no automatic close.

The model call

• There is no model in this system. Everything here is comparisons and durations, which is the correct level of sophistication for a safety record.
• The tempting use is predicting failures from the temperature curve. Battery level, door-open frequency and compressor cycle time already say it more directly.
• The wrong use is any judgement about whether stock is safe. Part 5 is entirely about why that decision needs a person’s name on it.
• Summarising a breach for the record is defensible, and the summary sits alongside the readings rather than replacing them.
• The cost page assumes none, which is why reading writes are the whole bill.

That is the whole system. Seven posts, one diagram at a time, and nothing in it that needs a server.

All posts