How I Designed the Backend for My Point of Sale System with Spring Boot

Introduction

In the first post, I shared an overview of POS Lite, a full stack point of sale system I have been building for small businesses, stores and gyms.

In this second post, I want to focus on the backend.

The backend is one of the most important parts of the project because it handles the core business logic, authentication, database communication and the API consumed by the frontend.

For this project, I built the backend using Java, Spring Boot, Spring Security, JWT authentication and PostgreSQL.

Backend Goals

Before writing the backend, I wanted to define a few goals.

The backend needed to be:

• Simple enough to understand and maintain
• Structured enough to grow over time
• Secure enough to protect private routes
• Clear enough for the frontend to consume
• Close to how a real business application would work

I did not want to build only a basic CRUD API. I wanted the backend to support real flows like authentication, inventory management, sales tracking and reporting.

Tech Stack

The backend uses:

• Java
• Spring Boot
• Spring Security
• JWT
• PostgreSQL
• Spring Data JPA
• Maven
• REST APIs

This stack helped me practice several common backend development concepts in one project.

High-Level Architecture

The backend follows a layered structure:

Controller → Service → Repository → Database

Each layer has a specific responsibility.

The Controller layer receives HTTP requests and returns responses.

The Service layer contains the business logic.

The Repository layer communicates with the database.

The Database stores the system data using PostgreSQL.

This separation helped me keep the project more organized and easier to maintain.

Main Backend Modules

POS Lite includes several backend modules.

Authentication

The authentication module handles user login and protected access.

It uses JWT so that the frontend can authenticate users and send the token when accessing private endpoints.

Products

The products module manages product information such as name, price, category and stock.

This module is important because products are used in inventory, sales and reports.

Categories

The categories module allows products to be grouped in a more organized way.

This makes the system easier to use when the inventory grows.

Inventory

The inventory logic helps track product stock and identify products with low stock.

This is one of the features that makes the project feel closer to a real-world business system.

Sales

The sales module handles sales transactions.

This part connects products, quantities, prices and totals.

It is one of the most important flows in the application because it represents the main operation of a point of sale system.

Reports

The reports module is used to generate useful information from the system data.

For example:

• Sales reports
• Inventory reports
• Low stock reports

This helped me think beyond basic CRUD and more about how users would actually use the system.

API Design

The backend exposes REST endpoints that the frontend can consume.

Some example routes are:

POST   /api/auth/login
GET    /api/products
POST   /api/products
PUT    /api/products/{id}
DELETE /api/products/{id}

GET    /api/categories
POST   /api/categories

GET    /api/sales
POST   /api/sales

GET    /api/reports/sales
GET    /api/reports/inventory

The goal was to keep the API predictable and easy to understand.

A clear API structure makes frontend development easier because each module has a defined purpose.

Authentication with JWT

Authentication was one of the most important backend features.

The general flow is:

1. The user logs in with valid credentials.
2. The backend validates the credentials.
3. The backend returns a JWT token.
4. The frontend stores the token.
5. The frontend sends the token when requesting protected resources.

Protected requests include the token in the authorization header:

Authorization: Bearer <token>

This helped me understand how stateless authentication works in a full stack application.

Database Design

The database was designed around the main entities of the system.

Some of the main entities are:

• Users
• Products
• Categories
• Sales
• Sale items
• Inventory records

A simplified relationship would look like this:

Category → Products
Sale → Sale Items
Product → Sale Items
User → Sales

This structure allows the system to track which products belong to each category, which products were sold and how sales are connected to users.

Challenges

One of the biggest challenges was deciding how to organize the backend so it would not become messy as the project grew.

At first, it is easy to create endpoints quickly. But as more features are added, structure becomes more important.

Some questions I had to think about were:

• Where should the business logic live?
• How should the API responses be structured?
• How should protected routes be handled?
• How should database relationships be modeled?
• How can the backend stay maintainable as new modules are added?

These decisions helped me understand backend development beyond just writing endpoints.

What I Learned

Building the backend helped me improve in several areas:

• Structuring a Spring Boot project
• Creating REST APIs
• Working with PostgreSQL
• Using Spring Data JPA
• Implementing JWT authentication
• Separating responsibilities between layers
• Thinking about business logic
• Designing backend modules for a real application

The biggest lesson was that backend development is not only about making endpoints work.

It is also about designing a structure that can support the application as it grows.

What’s Next

In the next post, I will focus on the frontend side of POS Lite.

I will share how I built the interface using React / Next.js, how the frontend communicates with the backend and how I structured the main screens of the application.

Thanks for reading.