BE (social-service) - Internal Verification Endpoint (Security)

[ImeshGimshan]

Internal Verification Endpoint (Security)

Description

Create a high-performance internal endpoint for inter-service communication. This endpoint is designed to be called frequently by the Chat Service and other microservices to verify friendship status between two users.

Objectives

1. GET /internal/status/:user1/:user2

Returns the friendship status between two users with optimized performance.

Requirements:

• Return friendship status between user1 and user2
• Endpoint is for internal service-to-service communication only
• Optimize for speed (high-frequency calls from Chat Service)
• Implement caching strategy for performance
• Validate both user IDs exist before querying
• Handle bidirectional friendship relationships

Path Parameters:

• user1 (UUID): First user ID
• user2 (UUID): Second user ID

Response (200 OK):

{
  "user1": "user-id-1",
  "user2": "user-id-2",
  "status": "FRIENDS",
  "isFriends": true
}

Alternative Response (when not friends):

{
  "user1": "user-id-1",
  "user2": "user-id-2",
  "status": "PENDING",
  "isFriends":  false
}

Possible Status Values:

• FRIENDS: Both users are friends
• PENDING: A friendship request is pending
• NONE: No friendship relationship exists
• BLOCKED: One user has blocked the other

Error Cases:

• 400: Invalid user ID format
• 404: One or both users not found
• 500: Internal server error

---

Security Requirements

Authentication & Authorization

• Endpoint should only be accessible from internal services (same VPC/network)
• Implement API key or service-to-service token validation
• Restrict endpoint from public internet access
• Log all access attempts for audit trails
• Implement rate limiting to prevent abuse

Data Protection

• No sensitive user data should be exposed
• Return only friendship status information
• Ensure no user can directly access other users' friendship data through this endpoint
• Validate both user IDs before processing

---

Performance Optimization

Caching Strategy

- Implement Redis caching with TTL (Time To Live)
- Cache key format: internal: friendship:{user1}:{user2}
- Cache TTL: 5-15 minutes (configurable)
- Invalidate cache on friendship status changes
- Support cache bypass parameter for fresh data (internal use only)

Database Optimization

• Create database indexes on (senderId, recipientId) and (recipientId, senderId)
• Use database query optimization (avoid N+1 queries)
• Consider denormalization if high-frequency queries warrant it
• Profile query execution time

Response Time Target

• Response time should be < 50ms (with cache hit)
• Response time should be < 200ms (with database query)
• Monitor and alert on response time degradation

---

Implementation Details

Cache Invalidation Strategy

When status changes (POST /friends/request, PATCH /friends/accept):
- Invalidate cache for both directions:  
  - internal:friendship:{user1}:{user2}
  - internal:friendship:{user2}:{user1}

Example Usage (Chat Service)

GET /internal/status/user-123/user-456
Response: { status: "FRIENDS", isFriends: true }

Chat Service Logic:
if (isFriends) {
  allowMessage();
} else {
  blockMessage();
}

---

Integration Points

Services Using This Endpoint

• Chat Service (primary consumer)
• Notification Service
• Activity Feed Service
• Group Management Service

Metrics & Monitoring

• Cache hit rate percentage
• Average response time
• Error rate and types
• Service availability uptime
• Number of calls per minute (load monitoring)

---

Acceptance Criteria

• GET /internal/status/:user1/: user2 endpoint created
• Input validation for user ID format and existence
• Caching layer implemented with Redis
• Cache invalidation logic integrated with friendship operations
• Response time benchmarks met (< 50ms with cache, < 200ms with DB)
• API authentication/authorization implemented (internal only)
• Rate limiting configured and tested
• Unit tests for happy path and error scenarios
• Load testing performed (simulate Chat Service call volume)
• Performance monitoring and alerting configured
• API documentation with security warnings
• Integration tests with Chat Service (mock)

---

Additional Notes

• Consider implementing a request/response compression if dealing with high volume
• Monitor cache efficiency and adjust TTL based on usage patterns
• Consider implementing a GraphQL query for multiple status checks in one request (future optimization)
• Document rate limit thresholds for internal services
• Plan for graceful degradation if cache is unavailable