I'm designing a microservices architecture for a social media–like system and need guidance on service boundaries and cross-service validation.
Current Design
I have two separate microservices:
Post Service → responsible for managing posts
PostLike Service → responsible for handling likes on posts
A PostLike references a PostId, but the services are fully decoupled (separate databases, no foreign key constraints).
Problem
When a user likes a post, I need to ensure that the post actually exists. Since the services are decoupled, this validation cannot be enforced at the database level.
This raises a few options:
Make a synchronous API call from PostLike Service to Post Service to validate the post.
Use asynchronous validation (event-driven / eventual consistency).
Skip validation entirely and accept potential inconsistencies.
Concerns
Synchronous calls increase coupling and latency.
Asynchronous validation may allow likes on non-existent posts (at least temporarily).
Skipping validation risks data integrity.
Alternative Consideration
I'm also questioning whether Post and PostLike should even be separate microservices.
Would it be better to keep them within the same service boundary?
Or is it reasonable to separate them and handle consistency differently?
Questions
Is separating Post and PostLike into different microservices a sound design choice?
If they are separate, what is the recommended way to ensure that a post exists before allowing a like?
In real-world systems, is this type of validation typically strict, or is eventual consistency considered acceptable?
I’d appreciate insights from those who have built similar systems.