DistributedLinkedin - Social Network For Working Professionals.

Overview

Distributed LinkedIn is a social networking platform for working professionals, built as a Spring Boot microservice application. The project separates identity, profiles, posts, professional connections, notifications, and media uploads into independently deployable services.

The application is designed around clear service boundaries, REST-based communication, event-driven notifications with Apache Kafka, Neo4j graph relationships, and centralized routing through an API Gateway. Docker and Kubernetes provide a repeatable path from local development to deployment on Google Kubernetes Engine (GKE).

Project Milestones

Designing the LinkedIn Microservice Architecture

The first step was to break the platform into services with focused responsibilities:

• User Service manages profiles and professional user information.
• Posts Service handles creating, reading, updating, and deleting posts.
• Connections Service manages connection requests and professional relationships.
• Authentication Service handles registration, login, tokens, and access control.
• Notification Service consumes events and delivers activity notifications.
• Uploader Service manages profile images and post media.
• API Gateway provides a single entry point and routes requests to the correct service.

This structure keeps business logic isolated and allows services to be developed, scaled, and deployed independently.

Building the User Service and Posts Service

The User Service provides the foundation for profiles, while the Posts Service owns professional content and post interactions. Both services expose REST APIs and use Spring Boot conventions for controllers, services, repositories, validation, and configuration.

Keeping users and posts separate prevents one service from becoming responsible for the entire application. It also makes it easier to evolve the post domain without tightly coupling it to authentication or connection management.

Understanding Neo4j, Connections Service, and API Gateway

Professional relationships are naturally represented as a graph, making Neo4j a strong fit for the Connections Service. Users can be represented as nodes and relationships such as connections, requests, and professional links can be represented as edges.

The API Gateway exposes a unified public API while forwarding requests to internal services. It centralizes routing and provides a consistent place for cross-cutting concerns such as authentication checks, request filtering, and service access rules.

Adding Authentication to the Application

Authentication was introduced as a dedicated service so security responsibilities remain separate from profile and content management. The service handles user credentials, login, token generation, and authorization data.

Requests entering through the gateway can be checked before reaching protected endpoints. This makes authenticated access consistent across the User, Posts, Connections, and other services while keeping private credentials away from unrelated business logic.

Sending Notifications with Kafka

Apache Kafka connects services through asynchronous events. Actions such as a new connection request, accepted connection, or post-related activity can publish an event without requiring the originating service to call the Notification Service directly.

The Notification Service consumes these events and processes them independently. This reduces coupling, keeps user-facing requests responsive, and allows notification processing to be scaled separately as activity increases.

Adding the Uploader Service

The Uploader Service owns file and image uploads for profile photos and post media. Moving uploads out of the core services keeps media handling independent from user and post business logic.

The service also creates a clear boundary for validating files, managing storage integration, and returning media references that other services can use without handling the upload process themselves.

Setting Up a Kubernetes Cluster on GKE

Each Spring Boot service is packaged as a Docker image and described with Kubernetes resources. Deploying to Google Kubernetes Engine provides a production-style environment for running the services as separate workloads.

The deployment setup includes Kubernetes Deployments, internal Services, configuration, replicas, and container networking. This allows individual services to be restarted or scaled without taking the entire platform offline.

Setting Up Ingress and Deploying on GKE

Kubernetes Ingress exposes the application through a single external entry point and routes incoming paths to the appropriate internal service. This keeps the public API simple while the cluster maintains separate workloads behind it.

The final deployment combines Docker images, Kubernetes resources, GKE networking, and Ingress routing into one distributed application. It also provides practical experience with service discovery, external access, configuration, and deployment troubleshooting in a cloud environment.

Request Flow

1. A client sends a request to the public Ingress endpoint.
2. Ingress forwards the request to the API Gateway.
3. The gateway validates access and routes the request to the responsible service.
4. The service reads or updates its own data and returns the response.
5. Events that do not need to block the response are published to Kafka.
6. The Notification Service consumes those events and performs notification work asynchronously.

Challenges and Trade-offs

• Defining service boundaries without duplicating business logic across services.
• Coordinating synchronous REST calls while keeping services resilient to failures.
• Modeling connection requests and relationships efficiently in a graph database.
• Securing distributed APIs while keeping authentication centralized and maintainable.
• Designing Kafka consumers that can process events independently and reliably.
• Managing configuration, networking, replicas, and routing across a Kubernetes cluster.
• Keeping file processing isolated so large uploads do not slow down core platform operations.

What I Learned

• How to design a production-oriented microservice architecture with independent deployment boundaries.
• How Spring Boot services communicate through REST APIs and asynchronous Kafka events.
• How Neo4j represents professional relationships and graph-based queries.
• How an API Gateway centralizes routing and access control for distributed services.
• How Docker, Kubernetes, GKE, and Ingress work together to deploy a cloud application.
• Why observability, failure handling, configuration management, and clear service contracts matter in distributed systems.

Impact

This project turned a LinkedIn-style application into a practical distributed systems exercise. It demonstrates independent Spring Boot services, graph-based relationship management, event-driven notifications, centralized API routing, dedicated media handling, and Kubernetes deployment on GKE.