Repository navigation
Engineering decisions and interviews
These are explanations of the current design and its tradeoffs, not claims that every production concern has been solved.
| Decision | Reason | Tradeoff / next pressure |
|---|---|---|
| Modular backend application | Simple local operation and straightforward transaction boundaries | Extract services only if independent scaling or ownership justifies it |
| FastAPI owns permissions and prices | Client inputs cannot establish privileges or authoritative totals | Every write path must continue enforcing these rules |
| Decimal values and GBP strings | Avoid floating-point money errors | Explicit conversion is needed in clients |
| PostgreSQL plus Alembic | Durable relational data and repeatable schema changes | Migration rollout and recovery need operational planning |
| Generated OpenAPI types | Make frontend/backend contract changes visible | Compile-time types do not replace runtime validation or integration tests |
| Real API browser tests | Verify the frontend against implemented behavior | Slower and more operationally involved than isolated unit tests |
| Local catalog filtering | Sufficient for a six-product demo | The 100-item limit requires server-side search/pagination as scale grows |
| Vercel Hobby + Neon Free | Publish the portfolio without a card or hosting bill | Serverless runtime, quotas and cold starts; Azure is optional future migration |
- Purpose: explain that VINDOR is a portfolio shop and identify the working catalog and API scope.
- Architecture: follow a catalog request from browser to Next.js, FastAPI and PostgreSQL using the architecture diagram.
- Correctness: demonstrate exact GBP prices, input validation and the difference between customer and admin authorization.
- Evidence: open Swagger, call the catalog, then show named CI stages and a browser-test report.
- Next challenge: explain the implemented checkout transactions, concurrent last-item tests and idempotency; explain the hosted sandbox evidence and its limits.
Be candid: customer sessions and non-payment checkout are merged; sandbox payment implementation merged in PR #194 and hosted payment acceptance is verified on 8685cc1. CI passing and self-review are useful evidence, but neither is independent security certification or proof of enterprise readiness.
- Why keep the backend together instead of using microservices?
- What breaks if two shoppers buy the last item simultaneously?
- Why is a JWT signature insufficient without active-user and permission checks?
- What does the health endpoint prove, and what does it miss?
- How does a changed API schema reach the frontend, and where can runtime failures remain?
- How would you deploy a migration safely and recover from a bad release?
Use the portfolio plan to keep answers aligned with implementation.
The customer-session design for VIN-24 records implemented cookie, origin, expiry, logout and testing boundaries. HttpOnly host-only cookies keep bearer tokens out of client code; exact trusted origins protect writes. Logout clears the browser cookie without revoking a copied JWT. Password recovery and email verification remain separate follow-ups.
Engineering handbook · Repository · Versioned documentation