Microservices group project
It's useful to learn from failure and do post-mortems as well!
More information
Many might choose to only talk of their successes, though where's the fun in that? Here's a short story about an abject failure, that was a useful learning experience. A while back, people really bought into the benefits of microservices, along the lines of the Gartner hype cycle.
However, something that few consider are the operational complexities brought on by picking such an architecture, as well as the inevitable overhead of managing various project runtimes and configurations, making it so that picking microservices for smaller projects is likely to lead to failure!
What I did
I tried. I really tried, I think I wrote about 4-5 services in the planned system, set up the infrastructure, even set up CI/CD and helped my course mates out. Sadly, that wasn't enough, because some of the people didn't have professional experience, yet assigning individual services to individual people for them to develop those just isn't good enough - because if their APIs are the furthest thing imaginable from REST and aren't even well suited for solving the issues at hand, the overall system won't work.
What I learnt
It's not enough to have "your" services working. You either succeed or fail as a team, or as an organization. Therefore it's important that you both support your developers, as well as check their work, to make sure that the direction that you're working in is aligned with both the technical requirements, as well as the overall organization goals that you're striving towards.