Hey @kbastani, there's still quite a few fields in order_event, which I don't think we need, like restaurant_city, order_location_lat, etc. Or do we need them? The structure currently looks a bit like a mixture of an outbox table (essentially solely an event container) and an actual table for storing purchase orders with all the distinct columns, which is a bit confusing.

Slightly related: can we make last_modified an actual temporal column type like TIMESTAMP?

When it comes to an order delivery simulation, there are several resources that are constrained. For example, delivery drivers, perhaps the most important actor in the order delivery process, are constrained in their location and availability. To simulate this properly using a client-side resource scheduler, we need to create a fixed number of drivers around restaurant locations.

When a simulation is started, new Driver entities are created with geolocation coordinates nearby Restaurant locations. When driver GPS location updates are applied to the Driver domain object, a DriverEvent contains the details of the driver's location and availability to take new orders. When a Restaurant has an order that is ready for pickup, available Drivers within an arbitrary distance should be notified of order availability.

Current order delivery applications like UberEats provides a single item queue for accepting new driver requests. To implement this, a DriverRequest object should be a property of the Driver entity. A DriverRequest will remain actively available to accept unless another Driver accepts the request before others. The client-side workflow for this will drive the state of DriverRequest in a polling state (application checks for new requests when old requests are no longer available).

To push a DriverRequest to a Driver, an API should be implemented that queries the closest Restaurant where an Order is ready for pickup. This URL could be a command on the Driver API at /v1/drivers/{driverId}/commands/requestDelivery.

If the Driver is in a valid state, the action will search for the closest available Order within a minimum distance. Since this requires geospatial search, Apache Pinot will be used from the order-delivery-service to find available order requests. Since the GPS coordinates of a Driver are available within the context of the requestDelivery command, a geospatial search will select the available orders using Pinot. Because the Pinot query will have eventually consistent data, the requestDelivery action will be sure to check the current state of an Order in MySQL.

• [x] #12
• [x] #13
• [x] #14
• [x] Implement DriverRequest notifications
• [x] #15
• [x] #17

Hey @kbastani, some WIP here. I still need to look into "un-stringifying" this, but I'm blocked by https://github.com/kbastani/order-delivery-microservice-example/issues/4; the order service is mostly unresponsive and requests to place an order will time out. Eventually, the service dies with OOME. I'm not sure what it's doing 🤔 . Some notes on the current status:

• Messages are sent to the outbox.event.Order topic atm., but we can adjust that (the Order suffix is the value of a new aggregate_type column I added); any other preferences for the prefix? Could also just be Order, if you want.
• The current structure is like this:

{"schema":{"type":"string","optional":true},"payload":"{\"createdAt\":1624632622667,\"lastModified\":1624632622667,\"status\":\"ORDER_CREATED\",\"accountId\":1234,\"links\":[],\"orderId\":53}"}

I'll remove the schema part, making it that:

"{\"createdAt\":1624632622667,\"lastModified\":1624632622667,\"status\":\"ORDER_CREATED\",\"accountId\":1234,\"links\":[],\"orderId\":53}"

Finally, I'll unstringify it, making it that:

{ "createdAt" : 1624632622667, "lastModified" : 1624632622667, "status" : "ORDER_CREATED", "accountId" : 1234, "links":[], "orderId":53}

Java 16 is the current stable version, but the build fails due to some access restriction around Lombok (I suppose caused by the fact that --illegal-access=deny is the default starting with 16. A version update of Lombok might suffice potentially.

The "Expand JSON SMT" (https://github.com/RedHatInsights/expandjsonsmt/) is used for un-stringifying the outbox event payload. As this SMT only works for specific fields and not the entire message (see https://github.com/RedHatInsights/expandjsonsmt/issues/10), the payload is first hoisted into a temporary field, then un-stringified and finally promoted to the top level of the Kafka message value again.

Hey @kbastani, this gives a nice event structure finally:

{"createdAt":1624638360969,"lastModified":1624638371355,"status":"ORDER_ASSIGNED","accountId":62941725,"restaurant":{"id":4,"storeId":7946,"name":"California & Battery","city":"San Francisco","country":"US","latitude":37.793060302734375,"longitude":-122.3997573852539},"links":[],"orderId":976}

The topic is debezium.Order now. I think you can consume that data and sink it into Pinot now? Or is anything else needed for doing so?

When starting the order service without the load simulator even, it seems to be stuck in some busy loop:

CONTAINER ID   NAME                                                           CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O        PIDS
527c77df49b3   festive_brahmagupta                                            0.00%     28.46MiB / 7.775GiB   0.36%     8.26kB / 3.72kB   1.86MB / 0B      1
c93122ea001b   order-delivery-microservice-example_connect_1                  0.57%     970.3MiB / 7.775GiB   12.19%    1.14MB / 991kB    85.1MB / 106kB   43
c714f9ec6295   order-delivery-microservice-example_order-delivery-service_1   567.19%   2.323GiB / 7.775GiB   29.88%    36.4MB / 23.9MB   8.19kB / 86kB    35
dbf55ad8cfec   order-delivery-microservice-example_kafka_1                    1.39%     408.9MiB / 7.775GiB   5.14%     1.08MB / 1.25MB   22MB / 1.24MB    76
083867bef502   order-delivery-microservice-example_mysql_1                    0.10%     1.989GiB / 7.775GiB   25.58%    23.9MB / 36.4MB   47MB / 317MB     6341
796775e19440   order-delivery-microservice-example_zookeeper_1                0.06%     92.39MiB / 7.775GiB   1.16%     103kB / 85.2kB    49.9MB / 659kB   52

When running the heavy mode from scratch, compose immediately complains about missing (external) volume "db_data". The Readme can be extended to add this step.

Hey @kbastani, as discussed here's a PR for adding Debezium to the demo. This currently captures all the tables from the orderweb application, whereas eventually, it should only capture the outbox table.

Are you going to change the application so that it writes the events into such table, instead of directly writing to Kafka? If so, I then could update the Debezium configuration, so to read from that outbox table exclusively. Ideally, the outbox table would have a schema as described here. Then the outbox routing SMT in Debezium could pretty much be used as-is. No problem if not though (if you prefer other column names for instance), just let me know and I can configure things as needed.