Overview of Core Services

Architectural Goals for Core Services

Core Services Provide:

• An extensible framework to provide integration with homegrown or 3rd party services within a domain ¹.
• Orchestration of communication across domains.
• Enable request and response handling within a domain.
• Reliable, simple, and performant framework to develop solutions against.
• Abstraction from dependency on direct vendor integrations. By integrating across domains with core services, dependent code doesn't necessarily need to change when a 3rd party integration changes. ²
• Logical and appropriate use of infrastructure and communication patterns (queues, streams, databases, webhooks, etc...)

An Example Core Service

Below is a hypothetical payment system where the software system provides the ability to process and refund payments. This is not meant as an exhaustive illustration of a payment system, rather, it is an illustration of how payments could be implemented against a Core Service.

In the above diagram, the Core pieces are divided into a Core Services Platform and a Core Payments implementation:

• Core Services Platform is intended to be generic across all core services. It is the common framework against which specific core service implementations are written against. The Core Services Platform provides cross-cutting capabilities such as sending webhook messages, sending pub/sub messages, reliability and health-checks, and an orchestration model against which the specific core service can be written.

• Core Payments is a specific core service written for the payments domain. In this case, it defines a generic API which external systems can use to consume payment functionality. It is written on top of the Core Services Platform and can use the messaging and reliability functionality provided by the platform.

• Payment Routing is a specialized orchestration service which makes decisions about incoming requests and routes them to the appropriate payment processor.

All incoming requests go directly against the Core Payments and are passed through to the payment router.

In other Core Service implementations, there may not be a separate router and the core service itself would serve that purpose.

Core Services Platform

The Core Services Platform is intended to be the base framework across all core services. Specific Core Services are written against the Core Service Platform to take advantage of the cross-cutting functionality that the platform provides. These cross-cutting capabilities include sending webhook messages (and managing their delivery and retries), sending pub/sub messages, reliability and health-checks, and an orchestration model against which the specific core service can be written.

Specific Core Service

A specific implementation of a core service (such as Core Payments in the above example, or Core Orders, or something else) provides a custom API surface for the domain in question. All core services should follow a similar message processing pattern (below) where data is stored, extended, forwarded, and queried via the core service api surface.

Message Processing Pattern

All core services mainly follow the following processing pattern:

1. Receive data via REST endpoint
2. Store that data immediately in a local database
3. Send the data to any services that must be processed in real time.
   (Any service that could "fail" the transaction should be real-time. Everything else should be out-of-process.)
4. Return a result
5. Send data to all services that can be out-of-process / not real-time.

Example of a Core Orders Service

This is an example of how a Core Orders Service might process data.

Extensibility Pattern

All Core services are extensible. They provide the base functionality for a business process, and additional features are provided via extensibility endpoints.

Types of Extensions

Core services support real-time and non-real-time extensions.

Real-time extensions are services that can cause a message to enter a failure state and stop processing.

Non-real-time extensions are services that can be notified or perform their processing after a message has been received.

Notification Processes

Notification Event Messages (Pub/Sub)

WebHook Event Messages