Start Process

 Asynchronous Sub-Process vs Start Process Smart Service 

Have a look into the above thread.And go though the link Chaitanya provided.

Start Subprocess: Fire and forget - starts another process in the background without waiting for it to finish.
Async Process: More control - starts another process asynchronously but allows some monitoring and potential data retrieval after it's done.

Choosing Between Them:
If your main process doesn't depend on the subprocess and you don't need return data, use an start process for simplicity.
If some level of communication or control over the Async subprocess is necessary, consider using Start Process.

Shubham Aware said:

Async Subprocess: Fire and forget - starts another process in the background without waiting for it to finish.
Start Process: More control - starts another process asynchronously but allows some monitoring and potential data retrieval after it's done.

I think it's opposite. In Async Subprocess we can maintain relationship and we can pass data by reference

Yes correct! Thanks
I edited my reply.

Appian engines

The Appian engines are in-memory, real-time databases based on KDB and the K language. The engines provide extremely fast storage and retrieval of data and also contain low level logic for high volume operations like security and group membership checks.

A default Appian installation has 15 engines: 3 process execution engines, 3 process analytics engines, 6 other individual engines, and 3 to support legacy portal. Each engine serves a unique role in the Appian architecture.

The execution and analytics engine come in pairs and are expandable up to 32 pairs of engines:

• Process Execution: Manages process execution and data for associated process models. Also referred to as exec, PX.

• Process Analytics: Stores all relevant information that may be used in a report on a process. Also referred to as analytics, PA.

Additional execution and analytics engines can be used to load balance high process execution and/or reporting volume across more engines and more engine servers (in a distributed environment).

The following six engines play a significant and active role in current features:

• Content: Stores metadata and security settings for documents and their organizational structures (communities, knowledge centers, and folders). The actual document content is stored on the file system, not in the engine. Also referred to as collaboration, collab, CO.

• Collaboration Statistics: Contains statistics on document usage and storage. Also referred to as collab-stat, CS.

• Portal Notifications: Stores information about system notification settings. Also referred to as notif, notifications, NO.

• Email Notifications: Responsible for generating and sending notifications via email. Also referred to as notif-email, NE.

• Personalization: Stores information about users, groups, group membership, and group types. Also referred to as groups, PE.

• Process Design: Stores all information that pertains to the design of the process models within the application. Also referred to as design, PD.

The following engines support older features in the Apps Portal interface:

• Portal: Stores all information about pages in the Apps Portal interface. Also referred to as PO.

• Channels: Stores information about the portlet types that are displayed on portal pages in the Apps Portal interface. Also referred to as CH.

• Forums: Stores all of the topics and messages posted to discussion forums in the Apps Portal interface. News content in the Tempo interface is not stored in this engine. Also referred to as discussion forums, DF.