Meet LAIQA: our first step towards an event-driven architecture
Contents
TechWolf just shipped LAIQA (“Live AI Quality Assurance”), a lean microservice that measures the accuracy of our skills‑AI and, more importantly, validates the event‑driven backbone that will replace our aging monolith.
What we built
- Pub‑sub at the core. The Skill Engine API now fires employee‑updated / employee‑deleted events to Amazon SNS; LAIQA consumes them via SQS for fully asynchronous processing.
- Three serverless Lambdas, one weekly Bedrock job. One Lambda ingests events, a second triggers batch inference, and a third publishes QA metrics to CloudWatch + Grafana.
- Pragmatic fixes that matter. We dropped Aurora Serverless v2 for PostgreSQL after real‑world scaling hiccups, and enforced single‑responsibility, tight time‑outs, and DLQs on every function.
- Everything as code. Terraform lays the foundation; AWS SAM wires the serverless stack; embedded CloudFormation glues SNS➜SQS➜Lambda. Result: reproducible, environment‑agnostic deploys.
LAIQA isn’t just an internal tool, it’s the working blueprint for how TechWolf will ship every new capability: small, event‑driven, infrastructure‑as‑code, measurable from day one. Expect shorter release cycles, sharper analytics, and a skills engine that keeps pace with your business.
Read more about LAIQA on Medium.
Blog
Relevant sources
From guides to whitepapers, we’ve got everything you need to master job-to-skill profiles.
You still have to cook: what agents changed about how we build
We pointed an agent at a track of work one evening and found 32 merge requests waiting the next morning. The project shipped in two weeks instead of four, and those were the most draining two weeks of the year. This is what Specto is, and what still needs a human in the kitchen.
Beyond the code series: When code gets cheap, judgment gets expensive
One of our engineers went from idea to working dashboard in under a week. Then we paused it. AI has collapsed the cost of building software, which moves the hard question from "can we build it?" to "should we?". Why we're doubling down on the Product Engineer.
Platform series: rebuilding observability so any engineer can debug a failing request
An experienced engineer could spend 15-30 minutes on a failing request and still only have a hypothesis. Here is how we rebuilt observability on OpenTelemetry, ClickHouse and HyperDX, and what we found once we could follow a request across every hop. First post in our Platform series.
