1) Tech interview (full description below): write a POST handler in Node Js that would get an array of REST endpoints and issue issue a request to each endpoint to test it. Each REST endpoint is characterized by URL + verb + args + params + query string. Testing means verifying the response in 2XX. Implement blocking first, async next. Add re-tries. Handle errors correctly.
2) RnD Director's interview: design a microservice-based solution implementing apartment (e.g., AirBnB) management (by owners) and booking functionality (by guests). Add all components needed for handling high-volume traffic including DBs, queues and lambdas, caches (Redis), etc. Explain how your solution will handle the apartment management (adding/editing, etc.) workflow and the apartment booking/reservation workflow.
Coding question task:
Guesty Assignment - Batch Editing Service
Task Description:
We’ll simulate a work in a microservices environment, where we have a product that already
has some functionality implemented as different microservices (e.g. a Users Service).
We have a new requirement, to support the option to perform batch actions on our existing
services. This will allow us to create / update / delete multiple resources at once.
Since we want that functionality in all of our services, instead of updating all of them, adding
batch support, we want to create one new microservice - the Batch Editing service.
This new service will manage the batch job running of any other service in the system.
You are tasked with building this new Batch Editing Service.
The Batch Editing Service:
The service should have a single endpoint (POST “/batch”). It should be implemented with a
simple Express (NodeJS) app.
This endpoint will receive an action to perform, as well as an array of payloads, describing the
payload to be sent in each invocation of the action.
You should design and implement the endpoint, we recommend designing the request and
response of this endpoint based on the following guidelines:
Request:
Its request body should contain 2 objects:
1. The endpoint - an object defining the endpoint we want to call, comprised of:
a. The endpoint URL (e.g. https://c6m1lqyqwa.execute-api.eu-central-
1.amazonaws.com/latest/user/{userId})
b. The endpoint’s HTTP verb (e.g. GET, POST, PUT).
The payloads (parameters) for each invocation of the service - an array of objects, each
of them containing a list of the needed parameters. Different calls will require different
types of parameters, you should support both PATH parameters, and a request body for
this assignment.
Response:
The service should respond with the result status (success / fail) of each invocation (it’s possible
to get a partial success, e.g. 28 / 30 calls succeed, and 2 / 30 failed).
Example:
An example use case is: “update users with IDs [14, 29, 103], setting their age to 30”.
In this case, we’ll expect the service to have the following request and response:
1. Request:
a. The endpoint, the URL and HTTP verb needed to perform an update users
request, e.g.:
{
2.
verb: “PUT”,
url:“https://c6m1lqyqwa.execute-api.eu-central-
1.amazonaws.com/latest/user/{userId}”
}
b. The payloads array, with 3 objects, each describing the parameters needed to
run on one of the users. userId should be 14 for the first object, 29 for the
second, and 103 for the third. The requestBody should be the same for all 3
objects:
{
age: 30
}
2. Response:
a. We’d expect the result from the service to contain the 3 result statuses, one for
each invocation.
Challenges:
1. You should model the endpoint, make sure it supports both path parameters and a
request body, and can respond with different result statuses for different invocations
(under the same request).
2. Some of the calls may fail. In such cases, the Batch Editing service should retry calling
the function again (only perform 1 retry). If the service failed twice, the response should
indicate this invocation has failed.
Our services return an HTTP 503 (Service Unavailable) when this happens.
3. All of our existing services have Rate Limits. The new Batch Editing service must take it
into consideration when invoking multiple calls to the same service.
Our Rate Limit is set to 5 calls per 10 seconds. Invoking more calls will return an HTTP
429 (too many requests) error.
Guidelines:
1. 2. 3. All code must be written in javascript.
The code should use best practices, be clear and contain comments, and should be
easy for someone who didn’t write it to understand.
Since the assignment is time limited, there’s no need to implement unit tests.
We strongly recommend that you work in stages, first getting an initial version of the service
working (even if it doesn’t address all cases like rate limits and retries), and extend it after that.
If you do not manage to complete everything - make sure you have a working version of the
functionality you did manage to complete.
A partial, but working service, that can handle some cases (but maybe not retries