Patient Management System

Responsibility: This microservice is responsible for managing endpoints about patient records. The relationship between Kafka and Patient Service sends an event to the Analytics Service. The database of this microservice is PostgresSQL and it runs simultaneously with the microservice, thanks to docker-compose.

Responsibilities: This microservice is responsible for managing endpoints about doctor records. The database of that microservice is MySQL. The reason beyond this database selection, it's generally optimized for read-heavy operations and offers slightly better performance in that context.

Responsibilities: This microservice is responsible for managing appointments, verifying IDs, notifying other services with Kafka. The database of this microservice is PostgresSQL. It also has two services. One of the services is managing appointment process. With the help of Rest Template, this service verify the Patient ID and Doctor ID to create an appointment. Also, if any patient's payment process is successful then Kafka triggers an event for The Billing Service. The second service of this microservice is Cleanup Service, manages deleting outdated appointments every day.

Responsibilities: This microservice is responsible for creating billing records after appointments. It creates an invoice for a patient with invoice-generator API, and it stores invoice instances (PDF) on Billing Service image.

Responsibilities: This microservice is responsible for creating auth records. It generates an JWT token for accessing other endpoints

Responsibilities: This microservice is responsible for managing request routing, and API management.

• ✔Logger - slf4j -
• ✔REST API
• ✔Docker Compose
• ✔API Gateway Routing
• ✔Kafka
• ✔SQL

I chose a microservice architecture to achieve loose coupling, scalability, and independent deployments. Each service is responsible for a specific domain (patients, doctors, appointments, billing, authentication), which makes the system modular and easier to maintain. This design also allows services to use different databases and technologies depending on their requirements, rather than being restricted to a single stack. In addition, microservices enable fault isolation — if one service fails, the others can continue functioning, improving the system’s reliability

Each microservice has its own database to respect the loose coupling principle. I used PostgreSQL for the Patient Service because of its powerful relational features, JSONB support, and advanced querying capabilities, which fit patient data well. On the other hand, I chose MySQL for the Doctor Service since it is lightweight and efficient for handling structured data with high read/write operations.

I used Apache Kafka for asynchronous, event-driven communication between services. Instead of relying only on HTTP calls, Kafka enabled me to build a scalable and fault-tolerant data pipeline. Producers generate events (such as patient updates or logs), and consumers process them independently, which reduces coupling and improves system resilience.

Docker allowed me to containerize services and databases, ensuring they run consistently across environments. Volumes were used to persist user data. Kubernetes provided orchestration features such as service discovery, load balancing, scaling, and persistent storage management, making deployments production-ready and easier to maintain.

I implemented an API Gateway to act as the single entry point for all requests. This simplified routing, authentication, and abstraction, since clients do not need to know individual service endpoints. It also centralized security and cross-cutting concerns like logging and request filtering, improving both usability and maintainability.

I set up GitHub Actions to automate build, test, and deployment pipelines. This reduced deployment time to under 15 minutes and ensured multi-platform Docker images could be pushed and deployed to cloud providers (AWS, GCP, Azure). The CI/CD pipeline improved reliability, minimized human error, and made the project more production-ready.

I chose JWT (JSON Web Tokens) because it enables stateless and lightweight authentication, which is ideal in a microservices architecture. Tokens are passed with each request, so services can validate user identity without maintaining server-side sessions.