Architecture of a Modern Business-Critical Application

A business-critical application is defined by its operational stakes: if the system fails, core commerce halts, legal compliance is violated, or significant financial loss occurs immediately. Building these applications requires distinct architectural discipline compared to consumer software or generic CRUD web apps.

+-------------------------------------------------------------------------+
|                           CLIENT & API GATEWAY                          |
|         (Web SPA, Mobile Clients, B2B Webhooks, External APIs)          |
+-------------------------------------------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
|                         APPLICATION INTERFACES                          |
|         (REST Controllers, Rate Limiters, Request Validation)           |
+-------------------------------------------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
|                       DOMAIN SERVICES & WORKFLOWS                       |
|   (Business Rules, Finite State Machines, Orchestration Pipelines)     |
+-------------------------------------------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
|                     ALEGOR PLATFORM CAPABILITIES                        |
|  Identity & RBAC  |  Immutable Audit  |  Storage  |  Webhook Gateway    |
+-------------------------------------------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
|                       PERSISTENCE & EVENT BROKER                        |
|   PostgreSQL (Primary + Read Replica)  |  Redis (Cache)  |  RabbitMQ    |
+-------------------------------------------------------------------------+

Layer-by-Layer Architectural Decomposition#

1. The Application Interface Layer#

The top layer receives HTTP requests, webhook payloads, and WebSocket frames. Its responsibilities are strictly restricted to:

• TLS Termination & Header Sanitization
• Strict Schema Validation: Utilizing Form Request objects that reject unknown properties before controllers execute.
• Authentication Verification: Validating session cookies or Bearer tokens via the Identity Module.

// Application Controller strictly delegates to domain actions
final class InvoiceController extends Controller
{
    public function issue(IssueInvoiceRequest $request, InvoiceIssuerAction $action): JsonResponse
    {
        $dto = InvoiceIssueDTO::fromRequest($request);
        $invoice = $action->execute($dto, $request->user());

        return InvoiceResource::make($invoice)->response();
    }
}

2. Domain Services & State Machines#

Business logic must never leak into HTTP controllers or raw database triggers. Core operations are modeled as discrete Action classes or Domain Services governed by Finite State Machines (FSM). This guarantees:

• Deterministic Transitions: An invoice cannot jump from Draft to Paid without transitioning through Issued.
• Side-Effect Orchestration: State changes automatically emit domain events to trigger downstream notifications, ledger records, and audit entries.

3. Platform Capabilities & Shared Contracts#

Underneath the domain layer sits the platform engine. Instead of re-implementing auth, queuing, or file handling inside every domain model, domain services call typed platform contracts:

• AuthorizerInterface for policy checks.
• AuditLoggerInterface for tamper-resistant history.
• DocumentStorageInterface for presigned cloud storage.

4. Data Layer & Storage Isolation#

For business-critical reliability, data persistence must incorporate:

• Transactional Integrity: Complex operations execute inside ACID database transactions with explicit row locking (SELECT FOR UPDATE) to prevent race conditions.
• Separation of Read & Write Queries: Heavy analytical queries and reporting workloads are automatically routed to read replicas, preventing connection starvation on the transactional master.
• Logical or Schema Multi-Tenancy: Automated query scoping ensures tenant boundaries cannot be accidentally bypassed by developer oversight.

5. Background Jobs & Asynchronous Queues#

Any task that takes longer than 50 milliseconds—sending emails, generating PDFs, syncing with ERPs, or dispatching webhooks—must be dispatched to an asynchronous worker queue. Key architectural rules for workers include:

• Job Idempotency: Jobs must be safely retryable without producing duplicate charges or duplicated database mutations.
• Dead Letter Queues (DLQ): Failed jobs are sequestered after maximum retry attempts for developer inspection without clogging active queues.

// Idempotent background job processing
class SyncErpInvoiceJob implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public int $tries = 5;
    public int $backoff = 30;

    public function __construct(public string $invoiceId, public string $idempotencyKey) {}

    public function handle(ErpGatewayInterface $erp, LockProvider $lock): void
    {
        // Guarantee single execution per idempotency key
        $lock->block($this->idempotencyKey, 10, function () use ($erp) {
            $invoice = Invoice::findOrFail($this->invoiceId);
            $erp->pushInvoice($invoice);
        });
    }
}

Resilience and Fault Tolerance Checklist#

1. Graceful Degradation: When an external dependency (e.g., payment gateway or SMS provider) is down, the system buffers events locally rather than returning 500 errors to users.
2. Circuit Breakers: Repeated downstream integration failures trip circuit breakers, immediately serving fallback responses and alerting on-call engineers.
3. Automated Recovery: Infrastructure self-heals through health check probes, container auto-restarts, and database failovers.

Explore our Platform Architecture Overview or read How to Design Reliable Integrations.