Story Filler / A decision retrospective
The delivery constraints, hosting choices and operating trade-offs behind Story Filler.
I use my engineering-judgment framework to explain my choices, respond to challenges and check the evidence behind my answers.
Context Question Judgment Evidence
01 / The constraints
During the course
A three-month Professional Software Development assignment began as a two-person project. After the team changed about a month in, I had less than two months to complete it independently.
The scope included a working application, local Kubernetes demo, development records, testing and reports.
After the course
I wanted the project to remain available as a public demonstration, with very little hosting spend and infrastructure to maintain.
Occasional visits made idle resource costs and operating effort more relevant than supporting a large workload.
02 / Questions & answers
These questions were put to me during an AI-assisted review. The answers present my conclusions after discussion, with follow-ups showing how the reasoning was challenged. Additional technical context and implementation evidence are labelled separately.
Delivery under constraints
My answer
Complete a working submission that met the course requirements within the time remaining. Public cloud hosting came later.
I used Trello to organise the work and simulate the agile process required by the assignment, alongside the application, local Kubernetes demo and documentation.
Basis My account of the course project and delivery circumstances.
Hosting choice / Challenge & follow-up
My answer
The frontend, backend and database still form the same three-tier application. What changed was where I deployed the components and which infrastructure I needed to operate myself.
I wanted each component hosted in a way that suited its needs, while considering availability, reliability and cost. Running Kubernetes would leave me responsible for cluster operations, deployment configuration, service access and networking, plus database operations if I hosted the database in the cluster. Helm and Istio would be optional choices; the cluster itself would still need operating.
Managed services reduced platform work and focused my ongoing responsibilities on application configuration, credentials and secure, dependable connections between services.
Follow-up / A smaller Kubernetes alternative
My answer to the follow-up
I would still choose Cloud Run. Its free usage allowance suits this small, infrequently visited application. Scale-to-zero compute fits its occasional use, while a running cloud cluster would add ongoing capacity costs. I also factor in usage limits and charges from associated services.
Cloud Run provides the capabilities this backend needs. My greater familiarity with Kubernetes is one factor; the application's needs and budget are decisive.
Cost and user experience
My answer
I accepted slower initial access and limited capacity for an application with very little traffic.
In my own checks, the page became usable within roughly half a minute, which I considered acceptable for this demonstration.
I keep application updates, configuration and credentials as the focus of ongoing maintenance. That operating model fits this demonstration.
Implementation reference Configured compute limits
Slow requests / Challenge & follow-ups
My answer
For this low-traffic demo, I accept an occasional slow first load. The loading screen keeps visitors informed, and an error offers a manual Try Again path.
If I add explicit timeouts or automatic retries, I would choose the waiting window from measured request behaviour and limit repeated attempts. I would also check backend execution limits: ending the browser's wait and stopping server-side work are separate concerns.
Follow-up / A hypothetical timeout
My answer to the follow-up
I would treat the original request as potentially active. It may still be using resources when the next one arrives.
Reading the story list is a read-only operation, so a retry can reasonably start a new query. I would focus on controlling repeated attempts and checking how long backend work can continue. Frequent retries that overlap with unfinished work can put pressure on workers and database connections. For this ordinary read, I would keep each retry as a fresh request and focus on controlling overlap.
Follow-up / Locating the delay
My answer to the follow-up
I would check Neon first because it can suspend when idle. The faster second response makes cold start a useful hypothesis to investigate.
I would identify the slow API request in the browser, then compare the available Neon state records with Cloud Run request and instance-startup logs for the same period. Both services may need to start. If those events did not explain the delay, or later requests remained slow, I would investigate load, resource pressure and application errors.
Request lifecycle and design exercise
The frontend calls the Django story-list API, which reads the database and returns JSON. The UI handles loading, success and errors; Try Again starts a new request. The client uses the browser's default waiting behaviour and user-initiated retries. The follow-ups use hypothetical 30-second delays to explore diagnosis and timeout design.
03 / Supporting evidence
Retrospective prepared on from my project account and a source review. AI assisted with editing and checking technical descriptions. The original verification record covers 27–28 September 2026; the separate security review records the maintenance release on 3 November 2026.