Three Responsibilities of a Global Application (Part 2)

Source: Dev.to

In Part 1, I explained that at a global scale, trust is part of the architecture—not a feeling, but something the system must enforce and prove.
In this article I describe the three distinct responsibilities that enable a global system to grow organically.

Responsibility 1 – Execution (Business Logic)

What it does

• Runs business logic
• Processes requests
• Handles events
• Advances workflows

Typical AWS services

• AWS Lambda
• Step Functions
• EventBridge
• DynamoDB
• SQS
• SNS

Primary question answered

What does the system do for the business?

Optimization goals

• Correctness
• Scalability
• Resilience
• Isolation

When it becomes a problem

• Embedding compliance logic directly in business code
• Adding “just‑in‑case” logging everywhere without structure
• Leaking operational concerns into domain logic

Execution code should focus on doing the work, not on explaining or defending it.

Responsibility 2 – Auditing / Proof

Why it exists

Someone outside the team will ask questions such as:

• Who had access?
• Who changed production?
• What data moved where?
• Was logging enabled at the time?

These questions are about proof, not debugging.

AWS services that express this responsibility

• AWS CloudTrail
• IAM configuration and access records
• Configuration history & retention policies
• AWS Audit Manager

Common pitfalls

• Re‑using execution or observability data as evidence (logs change format, metrics are aggregated, dashboards get deleted, developers remember things differently).

Evidence must be

• Complete
• Consistent
• Tamper‑resistant

Because of these requirements, auditing must be kept separate from execution.

Responsibility 3 – Operations / Health Monitoring

Primary question answered

Is the system healthy right now?

(Not “What happened to tenant X?” or “Who changed this?”)

Typical concerns

• Are errors increasing?
• Is latency degrading?
• Is the issue regional or global?

Answers come from

• Metrics
• Alerts
• SLOs
• Dashboards

AWS services used

• Amazon CloudWatch metrics & dashboards
• Amazon Managed Prometheus
• Service telemetry & alerts

These services trigger investigations and actions when health signals cross thresholds.

Benefits of Separating the Responsibilities

• Clearer conversations

  • Instead of “Should we centralise logs?” ask “Which responsibility are we trying to serve?”
  • Instead of “Why can’t I just add tenantId to metrics?” ask “Is this an operational signal or an accounting question?”
  • Instead of “Why is governance slowing us down?” ask “Which responsibility are we trying to satisfy?”

• Explicit trade‑offs – decisions are made with the relevant responsibility in mind, reducing hidden complexity.

• Reduced confusion at scale – metrics with tenant IDs, audit dashboards, and debugging through CloudTrail each make sense in isolation, but mixing them leads to ambiguous signals.

From a governance perspective, global systems fail not because they are distributed, but because we ask a single system to do everything at once. Separating execution, auditing, and operational health puts complexity where it belongs.