updates interview exercise with error monitoring, rate limiting, and …

…search/scalability critical thinking question

README.md

@@ -35,7 +35,7 @@ The initial value of `state` is `pending`. The other possible value is `complete
 
 ---
 
-**GET** `/creators` - returns a list of creators. It accepts `sort`, `sort_direction`, `limit` and `offset` query params. 
+**GET** `/creators` - returns a list of creators. It accepts `sort`, `sort_direction`, `limit` and `offset` query params.
 
 The `sort` param determines which attribute of `creator` to sort by. The `sort_direction` param should accept either `asc` (ascending) or `desc` (descending)
 
@@ -49,7 +49,7 @@ The `offset` param defines how many records to skip in the results set. E.G. if
 
 ### Gigs resource
 
-**POST** `/gigs` - saves a `gig` record to the database. It should provide value for the `brand_name` attribute in the request body. The created gig should also be linked it to a given creator. 
+**POST** `/gigs` - saves a `gig` record to the database. It should provide value for the `brand_name` attribute in the request body. The created gig should also be linked it to a given creator.
 
 ---
 
@@ -61,7 +61,7 @@ The `offset` param defines how many records to skip in the results set. E.G. if
 
 ---
 
-**PUT** `/gigs/<id>` - updates the attributes for a given gig based on the ID. 
+**PUT** `/gigs/<id>` - updates the attributes for a given gig based on the ID.
 
 ## CRON
 
@@ -79,12 +79,34 @@ There should be some mechanism for changing the state for `gigs` and `gig paymen
 
 Your application should be using ActiveRecord so the underlying database shouldn't matter much. We will be testing using the PostgreSQL database.
 
+## Authentication & Authorization
+
+The API should ensure that not anyone can access it. Implement a basic system of authorization, we can assume that the user has authenticated with us previously and has the proper credentials.
+
+## Error Monitoring
+
+The API should have proper error monitoring and return errors that make sense downstream for person or application making the request. Internally, we want to monitor errors, especially 500s so we can implement bug fixes. Externally, we want to render common errors (ie. rate limited, not authorized, bad request, the 400's) in a way to users so they can uunderstand why their requests are failing.
+
+## Rate limiting
+
+The API should implement some basic form of rate limiting based on the request. Based on how you implement authorization, we'll also need to check that a particular user is not abusing our endpoints.
+
+## Scalability and Searchability
+
+Imagine the creators database is large - At least 1 million records. While the `GET /creators` endpoint supports some basic functionality - ie. pagination, sort, and limiting, it does not support searchability.
+
+If you had to design a scalable search on this endpoint, how would you go about doing so? This is a critical thinking question that we want you to include as part of the exercise, but do not expect you to implement. Think about issues of scalability and how you would solve them as well as design of the search feature.
+
+For example, the different attributes on a creator you might search (what would we know about a social media creator, imagine we have access to all the information on their public feed.) What if you could search by the types of images they post? Maybe they have a profile where they tell us more about them? Those are all examples of searchable criteria.
+
+The other part is the scalability. How would you architect a system to handle that quantity of records to query assuming it's only going to grow larger and larger (maybe exponentially)? This could include a plan to implement monitoring, solutions at the DB layer as well as monitoring layer.
+
 ## Testing
 
-Add whatever test coverage you deem necessary. Please use the [rspec](https://github.com/rspec/rspec-rails) testing framework. 
+Add whatever test coverage you deem necessary. Please use the [rspec](https://github.com/rspec/rspec-rails) testing framework.
 
 ## Deliverables
 
-To submit your project please archive the project folder in a ZIP and email it to `ian@popularpays.com` with the subject `Interview Practice Submission - <your name>`. 
+To submit your project please archive the project folder in a ZIP and email it to `justin@popularpays.com` with the subject `Interview Practice Submission - <your name>`.
 
-If the file size is too large to be attached to an email then upload it to Dropbox or Google Drive and email the link of the ZIP file. 
+If the file size is too large to be attached to an email then upload it to Dropbox or Google Drive and email the link of the ZIP file.