Movie-Buddy

Problem

Build a movie centric social application, in a two person team, in a way that demonstrates microservices architecture rather than just claiming it. The easy failure here is a monolith wearing four service names, where every service talks to the same database and nothing can actually be deployed on its own.

Constraints

• Two people, one term.
• The architecture had to be genuinely distributed, not a monolith split by folder.
• The whole thing had to run somewhere real, not only on a laptop.

What I built

Four or more independent services covering user authentication and movie CRUD, each exposing a REST API and each owning its own concerns. Services talk to each other through KubeMQ rather than by reaching into each other’s data, which is the line that decides whether an architecture is actually service oriented.

Java and Apache Tomcat behind the services, MySQL for persistence, HTML and CSS on the front.

Deployment. Each service is containerised with Docker and the system runs on Google Cloud Platform under Kubernetes, which handles orchestration, scaling, and service discovery.

Decisions and tradeoffs

Message broker over direct HTTP calls between services. KubeMQ decouples the services, so one being down does not immediately cascade. The cost is real: an asynchronous path is harder to debug than a function call, and you inherit message ordering and delivery questions you would not otherwise have. At this size, a direct call would have been simpler and would have been a defensible choice.