Building a Food Delivery Microservices Backend Using Spring Boot

Introduction

Designing and implementing scalable distributed systems requires moving away from traditional monoliths toward a decoupled architecture. To explore these concepts deeply, I built a food delivery microservices backend using Spring Boot. This project served as a practical sandbox for mastering microservice communication, API routing, security boundaries, and the database-per-service pattern.

Project Background and Goals

The primary objective was to engineer a robust, decoupled ecosystem representing an online food delivery domain. The application is broken down into four independent core microservices communicating securely behind a centralized gateway, utilizing modern Java and Spring ecosystem capabilities.

Core Technology Stack

• Java 21
• Spring Boot 3
• Spring Data JPA
• Spring Security & JWT Authentication
• Spring Cloud Gateway
• Spring Cloud Netflix Eureka (Service Discovery)
• RestClient for Inter-Service Communication
• Lombok & Maven

Microservices Breakdown

Each service in the architecture owns its domain model and database schema entirely, eliminating shared data dependencies.

1. User Service

Responsibilities: User Registration, Login, JWT Generation, Password Encryption via BCrypt, and account CRUD operations.
Database: food_user_db
Security: Stateless Spring Security with custom JWT filters.

2. Restaurant Service

Responsibilities: Managing restaurant metadata, including adding, updating, viewing, and deleting restaurant partners.
Database: foodapp_restaurant_db

3. Food Service

Responsibilities: Catalog management for menu items and pricing.
Design Decision: Instead of embedding full restaurant entities, records store only a foreign identifier (restaurantId) to maintain loose coupling across database boundaries.

4. Order Service

Responsibilities: Order placement, lifecycle updates, and total price calculation.
Workflow: When an order is initiated, this service coordinates synchronously with the User Service to validate customer profile validity and with the Food Service to verify item availability and current pricing before persisting the transaction.

Infrastructure and Routing Layer

Managing direct client-to-service calls can introduce tight coupling and security vulnerabilities. To address this, the architecture implements centralized infrastructure components.

• API Gateway (Port 8080): Acts as the single entry point for all client traffic, handling centralized request routing, security inspection, and path forwarding.
• Service Discovery (Eureka Server): Enables dynamic registration and lookup of microservice instances, allowing services to locate and communicate with each other dynamically without hardcoded hostnames or ports.

Architecture Overview

The system relies heavily on the Database per Service pattern to ensure complete isolation, high cohesion, and independent deployability.

Client
  │
  ▼
[ API Gateway (8080) ]
  │
  ├───────┬───────┬───────┐
  ▼       ▼       ▼       ▼
User    Rest.    Food   Order
  │       │       │       │
MySQL   MySQL   MySQL   MySQL

Request flow follows a clean gateway pattern: Client -> API Gateway -> Microservice Routing Layer -> Isolated Database.

Design Patterns and Engineering Principles

Throughout implementation, standard architectural patterns were applied to maintain code cleanliness and testability:

• DTO Pattern: Prevents database entity leakage across network boundaries.
• Builder Pattern: Simplifies complex object construction cleanly.
• Repository Pattern: Encapsulates data persistence logic.
• Constructor Injection: Ensures immutable dependency wiring and effortless unit testing.

Challenges Encountered

Building a multi-service architecture from scratch presented several debugging and design hurdles:

• Resolving JSON serialization mismatches during DTO mapping across network boundaries.
• Configuring stateless JWT security filters across both the API Gateway and downstream services.
• Managing HTTP 403 and 404 errors during inter-service RestClient calls.
• Handling schema migration synchronization across four distinct MySQL instances.

Best Practices Learned

Practical experience highlighted critical rules for distributed design:

• Never directly access another microservice's database table or share entity models.
• Always validate payloads returned by external service calls before processing downstream logic.
• Centralize cross-cutting concerns like authentication validation and routing rules at the API Gateway layer.

Future Roadmap

To evolve this project toward production-grade enterprise architecture, upcoming iterations will incorporate:

• Containerization and orchestration via Docker and Kubernetes.
• Resiliency patterns using Resilience4j (Circuit Breakers and Rate Limiters).
• Asynchronous event-driven communication using Apache Kafka or RabbitMQ.
• Distributed tracing and observability via Zipkin, Prometheus, and Grafana.

Conclusion

Building a food delivery microservices backend provided deep insights into the operational realities of distributed backend engineering. Transitioning from simple service calls to managing network boundaries, security contexts, and database separation builds a strong foundation for scalable system design.

Key Takeaway: Successful microservice design requires strict domain boundary enforcement, complete database isolation per service, and centralized routing to minimize client-side complexity.

Frequently Asked Questions

❓ Why use a database-per-service pattern instead of a shared database?

A database-per-service pattern ensures loose coupling and fault isolation, preventing schema locks or cascading failures from affecting multiple business domains.

❓ How do microservices communicate with each other in this project?

Microservices communicate synchronously using Spring's modern RestClient routed dynamically through Eureka and the API Gateway.

❓ What is the role of Spring Cloud Gateway?

The gateway acts as a single point of entry, managing request forwarding, security token inspection, and cross-cutting edge concerns.