Dog Breed Identifier - Challenges & Design Trade-offs

This page covers what did not work the first time and the changes I made to improve the demo without turning it into something bigger, more expensive, or harder to operate.

The AWS architecture was fine. The problem was the public demo experience: early predictions were inconsistent, and first-time visitors could hit a slow response after the system had been idle for a while.

Earlier architecture path

Earlier in the project, I also explored an ECS/Fargate-based path for serving the model. After testing and auditing the live demo, I kept the production version Lambda-based because it was simpler to operate, cheaper for unpredictable traffic, and a better fit for a public portfolio demo.

What broke

The first version used an ONNX-based inference approach. It looked reasonable on paper, but real-world dog photos produced very inconsistent results outside ideal lighting and framing.

In the revised version, I kept the same core AWS architecture but switched to a model based on the Stanford Dogs dataset so the breed labels were clearer and the results were more consistent.

• Prediction trust — visitors could reasonably question whether the system was working.
• Demo quality — weak outputs damage confidence fast.
• First impression risk — slow first requests can look like a broken site.

That was the real lesson: for a portfolio demo, the architecture alone is not enough. If the result looks unreliable, most people will not care how the backend is built.

What I changed

I did not replace the core architecture. I kept the same basic design: static frontend, direct S3 uploads, a protected public API, container-based Lambda inference, and DynamoDB for storing results.

• Model packaging — the model is now built into the container image instead of being downloaded during a request.
• Model approach — I moved to a more reliable image classification path based on the Stanford Dogs dataset, which gave the demo clearer breed labels and more consistent results.
• Cold-start mitigation — I added an EventBridge warm-up path so visitors are less likely to hit a slow first request.

These changes made the demo more consistent and responsive without adding always-on compute or bloating the architecture.

What I deliberately did not change

• I did not turn the system into an always-on service.
• I did not add extra AWS services unless they solved a real problem.

Architecture impact

The core live flow stayed the same:

• Browser uploads the image directly to S3 using a short-lived upload request generated by a dedicated Lambda function.
• Prediction requests go through CloudFront and AWS WAF to API Gateway.
• A container-based Lambda reads the image from S3, runs inference, and stores the result in DynamoDB.

In other words, I improved how the system runs without rebuilding the whole thing.

Key takeaways

• User trust matters — believable results matter more than a clever architecture diagram.
• Predictability matters — first-request performance is part of reliability.
• Restraint matters — targeted fixes beat unnecessary redesigns.
• Cost matters — public demos need to stay affordable when traffic is unpredictable.

The result is a public demo that works better, stays simple, and does not cost more than it needs to.