Skip to content

Technical Discussions

Jump to bottom
Jaafar Alkaales edited this page Jun 3, 2025 · 5 revisions

Goals

As mentioned earlier, the primary goal of this project is proof of concept, so the project has its pitfalls and limitations. Amongst those limitations:


  1. A user can retrieve all reservations and properties listed regardless of if they belong to that user or not.
  2. Payments and Notifactions microservices do not store any data into any storage.
  3. Both Payments and Notifications services are too small to be developed as microservices, however, i built them to prove the concept of MSA and TCP.
  4. Since the overall architecture relies on Synchronous inter-services communications, they are tightly linked in a chain i would depict it as follows:
    Reservations Microservice => Property-Catalog Microservice => Payments Microservice => Notifications Microservice

(Assuming the user is already logged in.) In this chain, priorities flow from left (highest) to right (lowest). If any service—especially one earlier in the sequence—goes down, it interrupts the entire booking process.

one solution to this is to utilize a message broker (i.e, Kafka or RabbitMQ). This approach will transform the design to a Asynchronous Architectural Pattern which decouples the services and increases resilience in the system.
Another improvement i would consider is, I pass the responsibility to the API-Gateway to emit events and send TCP messages to the target microservice. This will not only make each service unwary of one another,but will also increase resilience and the level of decoupling between each service.

API GATEWAY

Routing

The API Gateway in this project serves 3 main purposes :

  1. Re-routing the incoming request to their respective microservices via HTTP protocol.
  2. Handling authentication and authorization.
  3. Implementing circuit breakers.

now for the re-routing part, i do a bit of simple but effective logic. And that is by extracting the path, deconstruct it, and then map the result to its respective microservice. You can see the implementation here: Mapping to Respective Service

It’s worth noting that each service’s address comes from the Eureka Server. Since all services register there, looking up their location in Eureka adds an extra layer of resilience. The lookup happens using the appId of each service, which should be known to the developer by default.

Frontend

I completed about half of the frontend implementation, but due to time constraints, I decided to pause development.

Clone this wiki locally