Demo · 7 September 2026
Fullstack Test Shop
Angular catalogue, NestJS API, orders in PostgreSQL. A worker handles payment and delivery. Suppliers are HTTP mocks in the demo. It includes timeout, repeated webhook and order recovery scenarios.
01 / The task
Digital goods shop
A double click or repeated webhook must not create another order or deliver another code. If the supplier does not respond, the previous request needs to be checked before sending a new one.
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.
Screenshots
Screens, forms, errorsScreenshots, diagrams and source evidence retain their original language; captions and descriptions are translated.
02 / Technology
Stack
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.
03 / 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.
04 / 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 ↓