InstaStore

InstaStore is a microservice in charge of selecting the closest "convenience" store to deliver a groceries order to our B2B clients.

Questions and Answers

Search Criteria and Logic

• Q1❓: Is the nextDeliveryTime field used as a criterion to indicate the nearest store, or is it outside the scope of the test? For instance, if I have some stores, one closer than others, but its next delivery time is longer, should I look for the nearest one with the shortest possible delivery time?

  📝 A1: The "nextDeliveryTime" field can be seen as the next time slot where that store can deliver an order to a customer. If you want to use such a field as a deciding factor within the proximity and thus store resolution of your system, that's fine. You can make whatever definition you think is appropriate.

• Q2❓: Similarly, for the isOpen field, should I return the nearest store that is open, or simply the nearest one regardless of its status?

  📝 A2: You can also define whether and to what extent the "isOpen" field has an impact on the resolution of nearby stores. You can tell us about your decision in the Readme of your project.

• Q3❓: What criteria should be used to determine if a store is available? For example, it is open because it has inventory, due to its operating hours, etc.

  📝 A3: You can define and/or delimit the scope of the solution you propose according to the time limit and time availability you have. My recommendation is that it mainly corresponds to the values required as a test answer, no more, no less.

• Q4❓: How is the "nearest store" defined? What type of algorithm or distance metric should be used? (Euclidean, Haversine, etc.)

  📝 A4: You can use the distance calculation algorithm and its implementation that best suits you given the conditions required for your solution.

• Q5❓: Is there a maximum distance range within which we consider a store "nearby," or should I search worldwide for the closest one?

  📝 A5: There is no definition of the maximum distance range that restricts the response of the solution. You can make the definition that you think best, if in reality it does not make much sense to find a store unreasonably far away, you can take it into account.

Data Persistence

• Q6❓: Do you require the use of any specific database, or can I implement a mock with Fake Data in JSON or use a library that simulates a service? If I decide, what would be a plus for you in the test?

  📝 A6: There is no previous data source, the solution invites you to design and implement the one you think is best for the case. In case of decision, it is preferable to implement a data persistence source on mock data.

• Q7❓: Should I invent the store addresses or coordinates, or should I extract this information from a particular source? Do you know of any source you would like me to use?

  📝 A7: You can make up the data

Libraries and Tools

• Q8❓: Do you have specific libraries or tools you prefer to evaluate for developing the challenge?

  📝 A8: You only have the restriction of using Node.js + Express as mentioned in the challenge, feel free to choose the rest (including distance calculation if you prefer).

• Q9❓: Do you have any restrictions on which libraries I cannot use?

  📝 A9: You only have the restriction of using Node.js + Express as mentioned in the challenge, feel free to choose the rest (including distance calculation if you prefer).

• Q10❓: Should I deploy the service somewhere or have it run locally?

  📝 A10: You are free to deploy your solution wherever you wish, but it must be possible to deploy and run it in its entirety locally.

• Q11❓: To calculate the nearest store, can I use libraries or any third-party API, or would you prefer to see the logic used in the code?

  📝 A11: Feel free to choose whatever you want for the distance calculation if you prefer.

Language and Architecture

• Q12❓: Would you like the test to be developed using any particular architecture pattern?

  📝 A12: You are free to choose the architecture that best suits your solution, we invite you to tell us more about it in your Readme.

• Q13❓: Should I use JavaScript or TypeScript? If it is my decision, what would be a plus for the challenge?

  📝 A13: Typescript

Logs

• Q14❓: What specific information do we need to record from each endpoint call?

  📝 A14: You can determine the information that allows debugging of your solution in case of possible errors or failures effectively as a primary objective of your logs.

• Q15❓: How are we going to store these logs? Database, files, or some third-party monitoring service?

  📝 A15: You can choose the type of storage of these records, mainly to allow you easy and accessible access for monitoring.

Architecture

The InstaStore service architecture is a serverless microservice, using AWS and MongoDB services. It is based on the Hexagonal Architecture pattern (Ports and Adapters). In addition, we complement it with Vertical Slicing and Screaming Architecture to maintain a clear, scalable and maintainable structure.

Components

• API Gateway: Acts as the entry point for all client requests. Manages routing.
• AWS Lambda: Hosts the business logic of the service, executing code in response to API Gateway events. Each endpoint is backed by a Lambda function.
• AWS CloudWatch: Monitors and logs all requests to the service for performance monitoring and debugging.
• MongoDB Atlas: Stores data about the stores, including their locations, opening status and delivery times.
• AWS Secrets Manager: Securely stores configuration variables, such as the MongoDB Atlas URI and other necessary secrets.
• Swagger: Although it does not appear in the image, the documentation of the endpoints was done with Swagger.

Schedule

• Design and Configuration (6 hours)

  • Architecture design and requirements definition.
  • Configuration of the AWS environment (API Gateway, Lambda, CloudWatch, Secrets Manager) and MongoDB Atlas.
  • Scaffolding and libraries to use

• Basic Functionality Development (8 hours)

  • Implementation of business logic in the domain, additional configuration and connection of MongoDB Atlas.
  • Development of application services and infrastructure.

• Final Testing and Deployment (7 hours)

  • Service testing and requirements validation.
  • Bug fixes and final adjustments.
  • Final deployment and implementation review.

• Optimization and Documentation (5 hours)

  • Performance optimization and business logic tuning.
  • Implementation of the call logging system in CloudWatch.
  • Documentation of endpoints

Note: As stated above, I would divide the total hours into working days. I expect to deliver no later than Thursday, August 8, 2024.

How to run?

1. Clone the repository InstaStore
2. Switch to the development branch git checkout development
3. Install the dependencies, pnpm is recommended. pnpm i
4. Create an .env file in the root of the project. You can base on the .env.example file to see the environment variables.
5. Make sure you have mongoDB running locally. You can use for example https://robomongo.org/ or whatever you like.
6. If you already have mongoDB and environment variables configured. I recommend you to run the script to insert data into mongoDB. Run pnpm load:data.
7. To start the service run the command pnpm dev.
8. Open another terminal and enable the endpoint documentation by executing the command pnpm api:docs.
9. You can now use postman, insomnia or others of your choice to test the routes or from the Swagger UI itself.

Note: you can test the service using these urls

• GetAll: https://8mnws68wh7.execute-api.us-east-1.amazonaws.com/store
• GetById: https://8mnws68wh7.execute-api.us-east-1.amazonaws.com/store/4
• Closest store: https://8mnws68wh7.execute-api.us-east-1.amazonaws.com/store/closest?lng=-73.935242&lat=40.730610

Improvements and trade offs

1. What would you improve from your code? why?

   • Improve field validation using a validation library and schema declaration. You can use Zod or Joi.
   • Add better unit tests.
   • Review the folder structure to make it much more scalable.
   • Add an authentication system to the routes, such as API keys.
   • Perform stress tests and see how it behaves under a DDoS attack to add rate limiting.
   • Implement CI/CD.

2. Which trade offs would you make to accomplish this on time? What'd you do next time to deliver more and sacrifice less?

   • Automate deployments.
   • Have more context on the requirement so I can work faster and focus on business needs.

3. Do you think your service is secure? why?

   • I have good security; the service is deployed on AWS, and MongoDB Atlas is used. Having these services in the cloud already provides a very good security layer. However, I would like to control the IPs in MongoDB Atlas more, manage API Keys, configure a VPC in AWS, and thus have greater security control over the database.

4. What would you do to measure the behavior of your product in a production environment?

   • Currently, I am using CloudWatch and also the metrics of Serverless integrated with AWS. But I would like to add New Relic and Splunk; with these tools, I can measure the behavior of my service and create better filters and dashboards.