During my internship at MVP Studio, I’ve had the opportunity to work on Project Talent, a professional-grade platform built using a microservices architecture. As someone transitioning from learning monolithic applications to building distributed systems, this project has been eye-opening.

In this post, I’ll share the most valuable lessons I’ve learned while working on a real-world microservices project—from the architecture itself to team practices and deployment strategies.

---

🧱 Understanding the Core of Microservices

Before this project, I had only a theoretical understanding of microservices. Working on Project Talent helped me connect the dots. Here’s what stood out to me:

• Each service has a single responsibility: For example, there are separate services for Profile, Identity, Listing, etc. This enforces separation of concerns and makes the system easier to maintain.
• Services are independently deployable: One of the biggest advantages is being able to deploy changes to a specific service (e.g., Talent.Services.Profile) without affecting the whole application.

I also learned that while this sounds simple in theory, coordinating communication between services is where the real challenge begins.

---

🔁 Communication Between Services: Synchronous vs Asynchronous

One thing that caught me off guard was the variety of communication patterns used:

• Synchronous: Some services communicate directly via HTTP APIs.
• Asynchronous: Others use messaging queues like RabbitMQ for loosely coupled communication.

I learned that asynchronous communication is especially useful for operations that don’t require an immediate response. It improves scalability and resilience. However, it also introduces eventual consistency—something that developers need to account for.

---

🧪 Local Development: More Complex Than I Expected

In a monolith, you usually just npm start or dotnet run. But in a microservices system, local development can get tricky:

• I had to run multiple services simultaneously—sometimes using Postman or Swagger UI to test endpoints independently.
• I used tools like Docker and ngrok to simulate production-like environments.
• I learned the importance of mocking dependencies during development and testing. For instance, mocking RabbitMQ queues or external APIs allowed me to test services in isolation.

It forced me to improve my reading of logs, tracing of errors, and testing of services end-to-end.

---

🚀 Deployment: Lessons from Azure and GitHub

Publishing microservices to Azure isn’t a one-step process. I learned to:

• Replace all localhost URLs with the production Azure URLs to prevent broken service links.
• Remove all console.log statements from production builds to keep logs clean and professional.
• Use Git branching strategies (main, develop, module1/TalentProfilePage, etc.) to keep deployments stable and manageable.
• Push code to GitHub, create Pull Requests, and respond to mentor reviews (special thanks to Kester!)

These deployment practices taught me the importance of consistency, automation, and review cycles in real-world environments.

---

🧹 The Importance of Clean Code and Reusability

One lesson from my mentor, Kester, stuck with me: “Don’t make repetitive code with the same structure and response—extract a helper method instead.”

I refactored repeated talentId validation checks in ProfileController.cs into a helper method. It made my code:

• Easier to read
• Easier to maintain
• More testable

This experience deepened my appreciation for clean architecture and good coding habits.

---

🧠 Key Takeaways

Here’s a summary of what I learned about microservices from this experience:

• Microservices help scale teams and systems, but they also introduce complexity.
• Communication patterns (sync vs async) have trade-offs—choose wisely.
• Local development setups require planning and tools like Docker or mocks.
• Clean code and reusability are essential in a distributed system.
• CI/CD and deployment require attention to detail—especially with config, logging, and URLs.