Status: small historical prototype with a public repository. It demonstrates an end-to-end serverless vote path; it is not presented as a production survey platform.

The engineering question

A serverless diagram can look complete while hiding the details that determine whether the design is coherent: request validation, state updates, environment separation, failure responses, and deployable infrastructure.

This prototype asks whether a minimal poll can make that whole path inspectable without expanding into accounts, survey authoring, analytics, or administration.

System boundary

The browser renders a fixed poll and posts one selected choice to a FastAPI endpoint. The API reads the poll record, rejects unknown polls or choices, and applies an atomic DynamoDB update to the selected counter and total vote count. Mangum adapts the FastAPI application to AWS Lambda, and AWS SAM defines the function, HTTP API, DynamoDB table, and stage-specific configuration.

Poll creation, identity, duplicate-vote prevention, rate limiting, moderation, reporting, and operational administration are outside this experiment.

Static browser form -> HTTP API -> FastAPI on Lambda -> Atomic DynamoDB update -> Updated counts

Implementation and decisions

  • The API exposes a health route and one vote command: POST /polls/{poll_id}/vote.
  • A poll is stored under a single poll_id partition key with a choice-count map and total.
  • DynamoDB ADD updates both counters atomically instead of reading, incrementing, and rewriting them in application code.
  • On-demand table billing and a 256 MB, 10-second Lambda keep the prototype small and avoid capacity planning.
  • Separate development and production table names make environment boundaries visible in infrastructure rather than relying on operator memory.

The trade-off is deliberate simplicity. A single-item counter model is easy to understand, but it has not been load-tested for a hot poll and should not be treated as a proven high-throughput design.

Inspectable evidence

The public Survey/Poll application repository on GitHub contains the browser client, FastAPI handler, AWS SAM template, and environment configuration.

The repository supports the architecture claims on this page. It does not provide production traffic, scale, latency, availability, or user-adoption evidence.

Limitations and what remains unproven

  • The browser uses a configured API base and fixed poll identifier; there is no discovery or authoring workflow.
  • There is no authentication, authorization, voter identity, duplicate-vote control, abuse prevention, or rate limiting.
  • The prototype allows broad cross-origin access and would need a narrower origin policy before handling a real public workflow.
  • Errors are intentionally basic, and the repository does not demonstrate monitoring, alarms, backup, recovery, or incident handling.
  • No benchmark establishes how the single-record counter behaves under sustained concurrent voting.

Outcome and learning

The useful outcome is a small, traceable architecture rather than a long feature list. The prototype makes one request path concrete enough to inspect where validation belongs, why atomic persistence matters, and how infrastructure choices become part of the application contract.

It also shows where a prototype stops being evidence: a deployable path is not the same as an operated, secure, or scalable product.