The vault-account and (vault-)account-processor microservices form the core of the Account Service, the service which is responsible for creating and maintaining bank accounts in Vault.

There are two 'Account Processors' in Vault:

Account Processor v1 is the legacy processor (deployment name: vault-account-processor, used for processing plans.

Account Processor v2 (deployment name: account-processor) used for processing accounts.

(Processing here refers to the asynchronous processing of account updates. For example, account activation or account closure.)

If you are using Vault version 4.x.x and above then APv2 is deployed, although APv1 is still available for deployment. All earlier versions of Vault deploy APv1 only. The aim is to fully deprecate APv1, but for now, both are deployed in Vault version 4.x.x and above.

There are significant differences in the internals of APv1 and APv2, with APv2 being written in Golang, and being much more performant. For example, one replica of APv2 is enough to process a significant number of accountUpdates, so horizontal scaling is not needed for APv2.

More specifically, vault-account forms the core of all Account Service operations that interacts with the database, whilst vault-account-processor handles asynchronous operations that are typically more complex with multiple calls to different services, and thus taking longer to process.

vault-account is used for creating, tracking and maintaining bank accounts in Vault. The gRPC endpoints are available to be called internally by other services as well as being exposed to the Core API REST endpoints via the core-api-grpc upstream service. Certain methods publish messages to Kafka for the vault-account-processor to process jobs asynchronously.

vault-account-processor is used to perform asynchronous account update operations on bank accounts. This includes: handling contract activations, contract migrations, contract closures, and instance parameter updates. These operations are processed at timescales comparable to or larger than the gRPC response timeout limits, or involve a sequence of jobs that can be split into a series of gRPC calls and delegated accordingly. It consumes from Kafka, listening to the topic vault.core.accounts.account_processor.events, and executes the operations based on the account update type. The processor makes gRPC calls to the Account Service.