user-service

README

User-Service

Build and Run:

go mod vendor

docker build -t neiln3121/user-service .

Run with Mongo and Kafka using:

docker-compose up

To see messages run:

docker run --tty --rm --network user-service_default confluentinc/cp-kafkacat kafkacat -C -b kafka:9092 -t users

Description

My approach was to implement a REST API which queried a MongoDb database and notifified other services using Kafka messaging system. The main drivers for my choices were flexibility, independency and scalability.

• I chose MongoDB due to its scalability, availability and because it has no rigid schema. This allows for evolving data requirements

• I chose Kafka because of its strict message ordering and extended message retention allowing for the possibility of replaying past messages.

• I chose a REST API to help ensure system components remain properly decoupled so that they can be evolved more easily in the future

As the entity being handled is a 'user', I chose data integrity over performance. Whilst there is flexibility in the database due to no fixed schema, I wanted to maintain some degree of data consitency with the API as it can be easily changed. This was implemented using a validator to ensure mandatory fields and data quality (alphanumeric characters etc.). During an update, the current user data is retrieved first to ensure that the amended data is valid across all fields. This would be particulary important if any cross field validation was implemented. This does result in a performance impact but I've assumed that in most cases only an individual user will be amending their data.

For the REST API, I used some generic code I'd written previously for implementing standard CRUD operations. This code uses golang interfaces (found in repository) to enable new REST API to be implemented just from the go structure defined in models. The core interface is the IDItem interface (implemented in this case by the User model) which is used by the ItemCollection for implementing CRUD. The itemCollection is then used by the http handlers when each endpoint is called.The handlers will perform validation over the structure based on its validate tags.

Additional interfaces include the ItemFormData which holds additional information required for creating an IDItem but should not be stored with it, and the hashedItem interface for hashing the fields which need obscuring.

There is also generic code to create error messages for specific HTTP error codes using the display name for the model ('users') and for application setup for logging and config (either from env or cmd arguments).

For Production

• Deploy a reverse proxy for increased scalability and potential SSL termination
• Configure replication and sharding for Mongo
• Further Kafka instances