I'm diving into microservices architecture and have created a small e-commerce backend to practice my skills. My project has separate services for Catalog, Basket, Ordering, and Discounts. I'm wondering if this level of segmentation makes sense for my learning experience or if it's just too much complexity at this stage. I'm using .NET, CQRS, and RabbitMQ for events. What are your thoughts?
1 Answer
For learning purposes, splitting the services is a great idea! This fragmentation challenges you to tackle the difficulties that come with distributed systems. For instance, the 'Price Drift' problem is a classic issue you'll face. If a user adds an item to their basket and the price changes in the catalog, deciding whether to trust the basket's price or re-check the catalog presents a tough dilemma. Also, think about the Discount service dependency—if it fails, how will it affect checkout? It's overkill for a real product, but ideal for gaining hands-on experience. Embrace the pain; it means you're learning!
Thanks for the detailed breakdown! You're spot on about the "Price Drift" and Discount dependency issues; those are exactly the real-world challenges I wanted to tackle. I'm currently using event-driven price snapshots and future consistency checks, but I'm still fine-tuning. Appreciate the validation; keeping the split feels right for my learning. Thanks again!