Tamir Yirga

RabbitMQ into DynamoDB with Redis-cached reads, fronted by a token-bucket admission controller that samples queue depth every 200 ms and steers with AIMD. Retreat is a hundred times faster than recovery: it halves the rate on a severe backlog and claws it back ten permits a second. If the broker cannot be reached it holds the current rate instead of reading silence as an empty queue, which was the original bug.

Fleet awareness coordinates the instance count rather than the rate. Each replica heartbeats into a Redis sorted set and divides the admission floor by what it sees, because sharing one rate would collapse it by half for every replica. A shrink needs three consecutive confirmations, so a Redis restart cannot talk a replica into thinking it is alone.

The AWS run: 200,000 requests, every one a 200

4,309 req/s

Cardinality write requests on the DynamoDB counter

25,163

Same workload once HyperLogLog took over the counting

9,635

Defects documented, each one pinned by a regression test

38

Decision records, rejected alternatives included

11

Two rigs, two eras. The original ran on AWS, a Spring server on EC2 with RabbitMQ and DynamoDB behind it, and the one report kept from that build records 200,000 requests at 4,309 req/s with every response a 200. Everything after the rebuild ran against LocalStack on one laptop, where LocalStack is the binding constraint in every run, so read those throughput figures as a property of the rig rather than the architecture. Peak offered load in that sweep was 4,376 req/s and the controller shed hard above it. A batching result that looked like a 16% gain did not survive swapping the arm order, so it is not on this page. The CI workflow is written but has never actually run.

I owned the data layer. Clinical events live in JSONB because their shape changes by type, with a GIN index over the payload and a partial index that keeps soft-deleted rows out of the query path everything else uses. Deletes are soft throughout, so the audit trail survives.

The part that mattered most was the spec. Three teams were building against the same records, so I wrote the one document that says what a clinical event is: every enum lowercase, every field named exactly, and the required fields listed per event type. Blood pressure gets systolic and diastolic and never a generic value field. A named drug is always a medication, never a procedure, even when it is injected.

Flyway migrations behind the schema, seven of them mine

8

Containers in the Compose stack I assembled

6

Mental state values the spec allows, up from five

12

Team project, so the lines matter. The schema, the migrations, the event spec and the Compose stack are mine. The transcript confirmation gate, the Python extraction consumer and the architecture diagrams are other people's work, and so were the speech-to-text vendor comparison and the model-selection decision. Nobody measured throughput or latency on this, so there are no performance numbers to show.

The interesting problem here is not speed, it is measuring speed without lying to yourself. MPS and CUDA queue work asynchronously, so a timer wrapped around a forward pass measures how long it took to hand the kernels to the GPU, not how long the GPU spent on them. Every timed call is bracketed by a device synchronize, and ten warmup passes run first so Metal shader compilation stays out of the numbers.

Architectures through the same harness and hardware

4

Warmup passes before the clock starts

10

Timed passes per measurement

100

Straight answer: the harness writes its results into a gitignored directory, so nothing is committed that I can quote here, and I am not going to publish a throughput number from memory. Rerunning it and publishing the table is the obvious next step. This was a three-person course project and the architecture comparison was my track.

Threshold, segment, then describe each region with seven features chosen to survive rotation and scale: how much of its oriented box the region fills, aspect ratio, the first three Hu moments, compactness and extent. The thresholding, blur and morphology are implemented directly rather than called out of OpenCV, which was the point of the exercise.

The eigenspace path rotates each object onto its axis of least central moment, flattens it to a 64 by 64 patch, and projects that 4096 pixel vector onto 20 principal components. Matching happens in those 20 dimensions, and one image per object is enough to add it.

Principal components, down from 4096 pixels

20

Rotation and scale invariant features per region

7

Pixels sampled to estimate the threshold

6.25%

No benchmark is committed for this one. There are accuracy figures in the old write-up, but they sit in an example output block rather than a recorded run, so I am not going to repeat them. There is no timing code in the project either, which means I cannot honestly quote a frame rate. The demo video is the real evidence.