I am currently building a web platform and exploring the microservices architecture for my project. While studying system design and scalable architectures used by large platforms, I came across an important question regarding repository management for microservices, and I would like to get some insights from experienced developers in the community.

In a traditional monolithic application, we usually maintain a single repository that contains the entire codebase (frontend, backend, and supporting services). However, in a microservices architecture, the application is divided into multiple independent services, where each service handles a specific business capability such as authentication, booking, payments, notifications, etc.

My confusion is regarding the Git repository structure for such systems.

If we design an application using microservices, is it considered a best practice to create separate repositories for each microservice (for example: auth-service, booking-service, payment-service, notification-service), or is it also acceptable to keep all microservices inside a single monorepo while still maintaining them as independent services?

I am trying to understand:

What approach is commonly used in real production systems?
What are the advantages and disadvantages of monorepo vs multi-repo strategies in a microservices architecture?
How do teams manage shared code, versioning, and CI/CD pipelines in both approaches?
For a small team or a solo developer building a scalable platform, which approach would be more practical and maintainable?

I would really appreciate if experienced engineers could share real-world practices, architecture decisions, and recommendations based on production systems. My goal is to design the architecture correctly from the beginning and avoid restructuring the repositories later as the system grows.