Back

June 23, 2022

Event-Driven Microservice Architecture

Overview

  1. Architecture
  2. Data Models
  3. Event Processors
  4. Retry Mechanism

Architecture

architecture

Summary

  1. Services within an application communicate internally through a cache
  2. Services communicate with external upstream and downstream systems through a message queue (e.g. kafka, mq)
  3. Each service contains one or more event processor
  4. An event processor actively polls for new events from a data source (e.g. a cache or message queue)

Data Models

  1. Common Fields Of An Event Table
  2. Common Types Of Event Tables
  3. Message Types
  4. Statuses

Common Fields

An event table typically requires the following fields:

  1. EVENT_ID: A universally unique identifier for each event
  2. MESSAGE_TYPE: An enum that defines the type of event
  3. STATUS: Used to keep track of the status of the event processing
  4. CREATED_BY: Service that created the event
  5. CREATED_DTTM: Timestamp when event is created
  6. UPDATED_BY: Service that updated the event
  7. UPDATED_DTTM: Timestamp when event is updated

Example:

EVENT_ID SERVICE_MESSAGE_TYPE STATUS CREATED_BY CREATED_DTTM UPDATED_BY UPDATED_DTTM
a4e83689-37ee-40b3-a7db-10552d12a30d RQ_B_STP COMPLETED SERVICE_A 2019-10-12T07:20:50.52Z SERVICE_B 2019-10-12T07:20:50.52Z
a4e83689-37ee-40b3-a7db-10552d12a30e DR_C_POST COMPLETED SERVICE_B 2019-10-12T07:20:50.52Z SERVICE_C 2019-10-12T07:20:50.52Z
a4e83689-37ee-40b3-a7db-10552d12a30f RQ_B_STP UNPROCESSED SERVICE_A 2019-10-12T07:20:50.52Z SERVICE_A 2019-10-12T07:20:50.52Z

Common Types Of Event Tables

Inbound

Used to store event received from an external system.

Request

Used to store event initiated internally by a service to another service within the same application.

Response

Used to store event received from an external system.

Working Data

Used to store event data sent during request or received from response.

Payload

EVENT_ID TOPIC SOURCE_SERVICE TARGET_SERVICE PAYLOAD CREATED_BY CREATED_DTTM
a3e83689-37ee-40b3-a7db-10552d12a30d REQUEST_TOPIC_A1 UPSTREAM_A1 SERVICE_A {“event_id”:”a3e83689-37ee-40b3-a7db-10552d12a30d”,”message_type”:”RQ_A_INIT”} SERVICE_A 2019-10-12T07:20:50.52Z
a3e83689-37ee-40b3-a7db-10552d12a30d RESPONSE_TOPIC_A1 SERVICE_A UPSTREAM_A1 {“event_id”:”a3e83689-37ee-40b3-a7db-10552d12a30d”,”status”:”ACCEPTED”} SERVICE_A 2019-10-12T07:20:50.52Z
a3e83689-37ee-40b3-a7db-10552d12a30d REQUEST_TOPIC_B SERVICE_B DOWNSTREAM_B {“event_id”:”a3e83689-37ee-40b3-a7db-10552d12a30d”,”message_type”:”RQ_B_STP”} SERVICE_B 2019-10-12T07:20:50.52Z
a4e83689-37ee-40b3-a7db-10552d12a30d RESPONSE_TOPIC_B DOWNSTREAM_B SERVICE_B {“event_id”:”a4e83689-37ee-40b3-a7db-10552d12a30d”,”status”:”ACCEPTED”} SERVICE_B 2019-10-12T07:20:50.52Z

Message Types

An event processor processes events based on different message types.

Sample message types:

  1. RQ_A_INIT
  2. RQ_B_STP
  3. RQ_B_REJ
  4. DR_C_POST
  5. CR_C_POST

Statuses

Statuses are used to keep track of the lifecycle of each event. Common statuses include:

  1. UNPROCESSED
  2. IN_PROGRESS
  3. COMPLETED
  4. ERROR
  5. RETRY
  6. FAILED

Event Processors

TODO

Retry Mechanism

TODO