Architecture

Table of Contents

• Why it exists
• How: the four pieces
• How: one order through the system
• Tips

Why it exists

Every track needs something to test. Public demo sites are slow, rate-limited and change without notice. A client's system cannot be used for a public guide. So the playground is ours: a realistic shape (auth, a catalogue, a checkout, a payment callback, an admin back office) with none of the operational baggage.

How: the four pieces

Piece	Technology	Purpose
Shop and admin UI	Next.js 15	What Playwright clicks on
API	Spring Boot 3 (Java 21)	What JMeter and k6 hit; Swagger UI included
Database	Postgres 16	Real transactions, real contention
Mock payment gateway	SoapUI open source	Hosted pay page, signed callback, adjustable delay

How: one order through the system

One order touches every piece, in this order:

1. Load the shop. The browser gets the pages from web on port 3000.
2. Menu and order. The shop's JavaScript calls api on port 8080 directly, not through web. The api prices the order on the server and saves it in Postgres.
3. Create a bill. The api asks mock-gateway for a bill and gets back a payUrl. This call stays inside the Docker network.
4. Pay. The browser opens the payUrl on port 8090, and the customer clicks Pay.
5. Callback. The mock sends a signed callback to the api (http://api:8080, again inside Docker), and the api marks the order PAID. The mock then sends the browser back to the confirmation page on web.

Tips

• Playwright goes through the browser, so a UI test covers all five steps the way a customer sees them.
• k6 and JMeter skip the browser and web entirely. They send the same API calls a browser would, so load lands on the api and Postgres, which is where a real shop hurts first.
• Load scripts choose whether to include the payment hop. They can pay on the payUrl themselves (steps 3 to 5), or send autoPay: true to skip the gateway and measure order throughput alone. See For load testers.