- Send driver's location updates from mobile and forward them to a broker
- Store locations, compute if a driver is moving or not
- A driver status is not moving if he has driven less than 500 meters in the last 5 minutes
The service has two main features:
- compute and stores driver's status (isZombie) asynchronously consuming driver coordinate updated events. As such, the service leverages reactive caching,
- serve a driver's status synchronously through HTTP GET requests.
This service has been built following several architecture paradigms:
- Hexagonal
- Domain-Driven Design (DDD)
- Command and Query Separation (CQS)
- Even Driven Architecture (EDA)
- SOLID principles
Distance are commonly computed through Haversine or Vincenty formulas with slightly different results. Either distance formulas can be used in the service using application configuration. Strategy design pattern was an ideal candidate.
For the sake of time, critical aspects are covered by unit tests and integration tests.
- unit tests cover algorithm in charge of computing distance between coordinates
- integration tests cover the whole application workflow:
- produce coordinate events, which will update store with driver's coordinates and isZombie status
- retrieve a driver isZombie status
- Go >= 1.18
- Docker >= 23.0.4
Install dependencies by running:
$ make depsStart the infrastructure by running:
$ make infra-upStop the infrastructure by running:
$ make infra-downRun integration tests (you will need ginkgo test runner installed):
$ make integration-test$ make build
$ ./build/geo-tracking sAccess pages locally, such as:
Note: driver's coordinate and status are updated through events.
- Events can be easily produced running integration test ./integration/http_status_v1
- You will need to have ginkgo testing framework installed https://onsi.github.io/ginkgo/#installing-ginkgo