This assignment consists of three separate projects: three back-end projects built with Python FastAPI. To simplify sharing, all projects have been combined into a single repository. However, following best practices, each project should ideally be stored in its own separate repository. A demo section is included at the end of this README.
Given the DB schema (see below) create an endpoint for the signup request to handle a ‘sign-in three-times’ quest. You should keep track of the middle actions that happen before completing a quest.
- Quest Name: "Sign-in-three-times"
- Reward: 10 diamonds for logging in 3 times
- Reward Claiming: Manual (auto-claim is set to false)
- Maximum Claims: Reward can be claimed up to 2 times
- Streak Requirement: 3 logins required to claim the reward
If I had access to the necessary servers and time, I would set up the architecture as outlined below. This design is based on the following considerations:
- Traffic distribution: Using AWS ECS (or EKS), along with Fargate, helps evenly distribute traffic and optimize resource utilization.
- gRPC Communication: Implement gRPC for efficient, low-latency communication between the Quest Catalog Service and Quest Processing Service. This makes it quick to retrieve quest details and supports real-time data sharing.
- Redis Caching for Quest Catalog Service: Use Redis to cache frequently requested quest data, minimizing database queries and reducing latency for high-traffic requests. This improves the performance and scalability of the Quest Catalog Service by serving cached responses when possible.
- JWT Token for Authentication Across Services: Use JWT (JSON Web Tokens) to authenticate requests across all services, ensuring secure, token-based access. Each service validates JWT tokens on incoming requests to enforce security and user authentication consistently.
Currently, for the demo, all projects are deployed on a single server (AWS EC2 t2.micro) due to limited availability of separate servers. Only the back-end API's (a total of 3) are completed and available for testing.
The database schema was updated with two new tables: user_rewards and events. The user_rewards table is added to allow easy retrieval of users' reward history directly, without needing to access the quests table first. The events table records key actions, such as quest completions and reward claims, allowing the state to be reconstructed from historical events (Event Sourcing).
Additional columns were also added to the tables; further details can be provided during the technical review if needed.
Service for user registration and login
Service for getting quest information
Service for tracking user quests and managing rewards
- User Authentication Service: http://54.180.154.43:8001/docs
- Quest Catalog Service: http://54.180.154.43:8002/docs
- Quest Processing Service: http://54.180.154.43:8003/docs
Contributions are welcome! Please feel free to submit a pull request or open an issue for any suggestions or improvements.
This project is licensed under the MIT License.