In Spring, where does the issuance rule belong — the controller or the service?

The controller handles only the HTTP request/response boundary, while business rules such as a limit live in the service layer. This problem follows the same structure.

How do you verify an issuance API that has a limit?

Check not only the first successful issuance, but also a repeat request from the same user and separate requests from different users. A test that only exercises the success path can't tell whether the rule holds.

Event Coupon Issuance API

Your task

Build an API that issues event coupons. There's exactly one rule — each user may be issued a coupon only once. If a user who has already received one requests again, the request must be rejected. Complete CouponService.issue.

Ground rules

•Single instance, in-memory H2.
•Users are identified by the userId in the request.

Not required

•Concurrency, distributed environments (multiple instances issuing at once), distributed locks. Only single-threaded requests are considered.
•Authentication, authorization, coupon usage/expiry, inventory limits.

▶About this challenge

Complete an event-coupon issuance API built on Spring Boot 3 and JPA (in-memory H2). There is exactly one rule — each user may receive a coupon only once, and a user who already has one must be rejected on a repeat request. The controller handles only the HTTP boundary while the issuance rule lives in the service.

For an issuance with a fixed limit like "one per user," the key topic is whether the result stays the same when the same request arrives again. It is common for a button to be pressed twice, or for a request to be resent as a mobile network drops and reconnects. So for a write like issuance, the server itself has to take responsibility for how that limit is upheld. This problem deals with that limit rule within a single-instance, single-threaded scope.

In Spring, where does the issuance rule belong — the controller or the service?: The controller handles only the HTTP request/response boundary, while business rules such as a limit live in the service layer. This problem follows the same structure.
How do you verify an issuance API that has a limit?: Check not only the first successful issuance, but also a repeat request from the same user and separate requests from different users. A test that only exercises the success path can't tell whether the rule holds.

Event Coupon Issuance API

Your task

Ground rules

•Single instance, in-memory H2.
•Users are identified by the userId in the request.

Not required

•Concurrency, distributed environments (multiple instances issuing at once), distributed locks. Only single-threaded requests are considered.
•Authentication, authorization, coupon usage/expiry, inventory limits.

▶About this challenge

In Spring, where does the issuance rule belong — the controller or the service?: The controller handles only the HTTP request/response boundary, while business rules such as a limit live in the service layer. This problem follows the same structure.
How do you verify an issuance API that has a limit?: Check not only the first successful issuance, but also a repeat request from the same user and separate requests from different users. A test that only exercises the success path can't tell whether the rule holds.