Note: Didn't use lombok intentionally

Customer Reward API

This is a Spring Boot REST API that calculates reward points for a retailers customers based on their transaction history.

Reward points are awarded as:

• 2 points for every dollar spent over 100$
• 1 point for every dollar spent between 50$ and 100$ in a transaction.

Example:

A 120$ purchase = 2x(120 - 100) + 1x50 = 90 points

whereas,

A 70$ purchase = 1 x (70 - 50) = 20 points

Tech Stack

• Java 17
• Spring Boot 3.5.0
• Build Tool: Maven

To run this project locally

1. Install JDK 17
2. Clone repo using git clone https://github.com/dv-89/customer-reward-api.git
3. Navigate to project directory and run the application using ./mvnw spring-boot:run

The API will start on port 8080 by default.

API Usage

Query Parameters:

• customerId
• from (start date - inclusive)
• to (end date - inclusive)

Sample URL to test in postman:

http://localhost:8080/api/rewards?customerId=1&from=2024-01-01&to=2024-03-15

Sample JSON Response

{
  "customerId": "1",
  "customerName": "Dinesh",
  "totalPoints": 275,
  "transactionList": [
    {
      "customerId": "1",
      "transactionId": "T002",
      "date": "2024-02-05",
      "amount": 75.0
    },
    {
      "customerId": "1",
      "transactionId": "T003",
      "date": "2024-03-15",
      "amount": 200.5
    }
  ],
  "fromDate": "2024-01-20",
  "toDate": "2024-03-31",
  "monthlyBreakdown": {
    "February": 25,
    "March": 250
  },
  "transactionCount": 2
}

Explanation

Basically requesting the api to give the reward points for the customer ID 1, based on their transactions between Jan 1, 2024 and Mar 15, 2024. Also show all the necessary details regardinig the customer and transactions within the dates.

Data Types & Precision

• Transaction Amounts:
  Uses BigDecimal to ensure precision in financial calculations and prevent rounding or overflow errors.

• Reward Points:
  Stored as int. This supports up to 2,147,483,647 points per user, which is sufficient for most real-world reward systems.
  If extremely large values are expected (e.g., institutional-scale usage), consider upgrading to long or BigInteger.