Demo · 8 September 2026
Fullstack Test Shop
The test assignment is implemented as a complete digital shop flow: Angular storefront, NestJS API, PostgreSQL via Prisma, payment webhook, two key providers and a background fulfillment worker. The UI covers purchase, repeated payment events and recovery after stock or provider failures.
Product catalogue. External services are mocked.
01 / The task
Digital goods shop
The assignment asked for a digital goods shop with catalog, checkout and payment. I extended the base scenario with an idempotent webhook inbox, concurrency-safe key fulfillment, stage retries and observable failure states.
Use case: Digital goods checkout. This is a demo with mocked suppliers.
Work done
- Angular storefront, order page and status history.
- NestJS API, database schema, worker and HTTP mocks for two suppliers.
- Duplicate and failure handling, concurrent request checks, deployment.
- Added sessions, TTL, a reset for the visitor's own data and a controlled order failure for the demo.
02 / Implementation
What sets the implementation apart
Fulfillment happens once even under repeated or concurrent webhooks. A stable provider request ID survives an ambiguous timeout; out_of_stock and delivery_failed recover on a later worker pass. Database constraints and FOR UPDATE SKIP LOCKED enforce invariants at the storage layer.
Screenshots
Screens, forms, errorsScreenshots, diagrams and source evidence retain their original language; captions and descriptions are translated.
03 / Technology
Stack
Shares use Git application-file bytes at pinned revisions. Each file belongs to one subsystem under scripts/generate-stack-share.mjs rules; tests, assets, dependencies and generated files are excluded. Rounded to 0.1%. This describes code composition, not proficiency.
Angular / TypeScript
Storefront, state signals, HTTP client and order polling.
NestJS
Contracts, validation, webhooks, recovery operations and demo limits.
PostgreSQL / Prisma
Monetary snapshots, inbox, leased queue, unique indexes and transactions.
Node.js worker
Provider HTTP calls outside short transactions, retries and final delivery.
04 / Decisions
How the project works
- Prices and discounts are calculated on the server and saved in the order.
- A unique index protects Idempotency-Key; replayed input is checked against the original intent.
- Webhooks are saved to a durable inbox first. A separate worker processes payments and the delivery queue.
- The provider requestId remains stable across retries. An ambiguous timeout does not immediately allow a second code to be issued.
05 / Verification
Demo workflows
- Choose a product and complete a successful test payment. Wait for the code and inspect the history.
- Replay the same payment event: the code and delivery must remain unique.
- Create an order using the failure scenario, pay and select “Recover my order”.
- Check a declined payment, another session's UUID and resetting your own example.
Check results
- 14 meaningful screenshots of the actual interface retained.
- Each screenshot includes its date, scenario and code revision.
- Peak container RAM in the short test: 218.56 MiB. Shared services are counted separately; the shop includes its own database.
- 6 scenario repetitions measured; median 129.0 ms, maximum 1939 ms. Timing includes the browser and HTTPS; methodology and limitations are included.
Limitations
- Payments and providers are explicitly mocked; no money is charged and codes are for demonstration only.
- Up to 20 orders per session and 1,000 new demo orders in total. One-hour TTL, cleanup every five minutes.
- The recovery example deliberately fails the first delivery attempt for one order. It does not change global provider modes.
Technical notes
Modules, API, data model, setup and check results.
Documentation →Materials ↓