Most software systems do not fail because someone forgot to write code.

They fail because the system gradually accumulates architectural gaps.

A feature is added.

Then another.

A database query is written quickly.

An external API is called synchronously.

A secret is placed in configuration.

A log statement is added when production breaks.

An AI feature starts as a simple API call and stays that way even after the application becomes business critical.

Individually, these decisions may look harmless.

Together, they create a system that becomes increasingly difficult to scale, operate, secure, and change.

The interesting part is that many of these problems are invisible when the system is small.

A system with 100 users may tolerate poor indexing.

A system with one server may tolerate local session state.

A system with one dependency may survive synchronous calls.

A system with low traffic may survive direct database reads and writes.

The architecture starts showing its weaknesses when load, complexity, dependencies, data volume, or business criticality increases.

In this article, I will look at 10 architecture gaps that commonly appear in production systems.

This is not a guide to fixing them.

The objective here is simpler:

Recognize the gap before it becomes an outage, security incident, scaling problem, or revenue problem.

The corresponding fixes will be covered separately in Think in Systems.

1. Monolithic Tight Coupling

The gap

A monolith is not automatically a bad architecture.

The problem begins when components inside the system become so tightly coupled that a change or failure in one area can unexpectedly affect another.

Imagine a system containing:

Chat
  |
  v
Payment
  |
  v
Order
  |
  v
Notification

A change in the chat module should not unexpectedly bring down payment processing.

Yet tightly coupled systems can create exactly this kind of blast radius.

A seemingly isolated change can affect shared code, shared database tables, shared transactions, shared configuration, or shared resources.

Why it becomes dangerous

Tight coupling increases the number of things engineers must understand before making a change.

The real dependency graph becomes much larger than the visible feature.

A developer may think:

"I am changing the chat feature."

The system may actually behave like:

Chat change
     |
     +---- Shared library
     |
     +---- Shared database
     |
     +---- Shared transaction
     |
     +---- Shared configuration
     |
     +---- Payment
     |
     +---- Order

The result is a larger blast radius.

This is particularly dangerous in systems where different capabilities have different business criticality.

A failure in a recommendation feature should not have the same blast radius as a failure in payment processing.

Signals that you may have this gap

• Small changes require extensive regression testing across unrelated features

• Engineers are afraid to modify older modules

• Multiple teams depend on the same internal code or database structures

• Deployments frequently affect unrelated functionality

• A failure in one feature causes failures elsewhere

• Nobody can clearly explain the dependency boundaries

The deeper problem

The issue is not simply "monolith versus microservices."

A well designed monolith can have strong boundaries.

A poorly designed microservices system can have extremely tight coupling through synchronous dependencies, shared databases, and fragile contracts.

The architectural question is:

Can one part of the system change or fail without unnecessarily affecting everything else?

2. Synchronous API Chokeholds

Synchronous communication is useful.

A client sends a request.

The server processes it.

The response comes back.

Simple.

The problem appears when complex workflows are placed entirely inside synchronous request paths.

Consider a brokerage order workflow:

User
  |
  v
Order API
  |
  +--> Authentication
  |
  +--> Risk validation
  |
  +--> Balance validation
  |
  +--> Instrument validation
  |
  +--> Broker validation
  |
  +--> Order processing
  |
  v
Response

Each dependency can add latency.

If one dependency becomes slow, the entire request can become slow.

Now multiply that by thousands of concurrent requests.

You have created an architectural chokehold.

OWASP's Secure by Design guidance specifically calls out long synchronous chains across services as a reliability concern and recommends explicitly defining asynchronous semantics where appropriate.

Why it becomes dangerous

Synchronous chains couple the availability and latency of multiple components.

If:

A → B → C → D

then the user facing request may depend on the combined behavior of A, B, C and D.

A slow dependency does not remain isolated.

It can consume:

• Threads

• Connections

• CPU

• Memory

• Connection pools

• Request capacity

Eventually, a dependency problem can become an application problem.

Signals that you may have this gap

• Long request chains

• Increasing p95 and p99 latency

• Requests waiting on multiple downstream services

• Thread pools or connection pools getting exhausted

• Timeouts appearing during traffic spikes

• User facing APIs performing too much work before returning

The important question is:

Does this work really need to happen before the user receives a response?

3. Hardcoded API Configurations

Consider code like this:

const API_KEY = "sk_live_123456";
const ENVIRONMENT = "production";
const PAYMENT_URL = "https://payment.example.com";

It looks convenient.

It is also an architectural and security problem.

Configuration and secrets are now coupled directly to application code.

Why it becomes dangerous

Source code tends to travel.

It can exist in:

• Git repositories

• Developer machines

• CI systems

• Build artifacts

• Pull requests

• Logs

• Backups

• Forks

• Old branches

A secret committed to a repository can remain exposed even after the line is removed.

The larger problem is not simply where the API key is stored.

It is whether the architecture has a clear separation between:

Application Code
       |
       v
Configuration
       |
       v
Environment
       |
       v
Secrets

Security architecture guidance emphasizes controlled secret and key management, environment consistency, encryption, and least privilege.

Signals that you may have this gap

• API keys appear in source code

• Production URLs are hardcoded

• Developers manually change configuration before deployment

• Different environments require code changes

• Secrets are shared through chat or documents

• Rotating credentials requires a code deployment

The deeper question is:

Can the application change environments without changing its source code?

4. Missing Database Indexing

Databases can make millions of records feel fast.

Until they do not.

Consider:

SELECT *
FROM users
WHERE email = 'user@example.com';

With an appropriate index, the database may locate the relevant data efficiently.

Without one, the database may need to inspect a large portion of the table.

That difference becomes increasingly important as data grows.

The scaling pattern

A system might begin with:

10,000 users

The query appears fast.

Then:

1 million users

Still acceptable.

Then:

50 million users

Suddenly, a query that looked harmless becomes expensive.

The application has not changed.

The data characteristics have.

Why it becomes dangerous

Slow queries consume database resources.

That can lead to:

Slow Query
    |
    v
More CPU
    |
    v
More Concurrent Connections
    |
    v
Higher Latency
    |
    v
More Requests Waiting
    |
    v
Database Saturation

The problem can then spread to the application layer.

Signals that you may have this gap

• Queries become slower as data grows

• Full table scans appear in query plans

• Database CPU increases unexpectedly

• p95 and p99 database latency rise

• Application servers spend significant time waiting for database responses

• Queries were optimized for today's data volume rather than expected growth

Indexing is not simply a database optimization exercise.

It is an architectural consideration because data access patterns are part of system design.

5. Stateful Server Reliance

Imagine a user logs in.

The application stores the user's session on Server A.

Later, the load balancer sends the next request to Server B.

Server B does not know about the session.

Now the application has a problem.

             Load Balancer
              /          \
             /            \
        Server A        Server B
           |
      Session Data

This is a stateful server dependency.

The server is carrying information that other servers need.

Why it becomes dangerous

Horizontal scaling assumes that requests can be distributed across multiple instances.

But local state creates a dependency on a specific machine.

You can end up with:

1 Server
  ↓
2 Servers
  ↓
4 Servers
  ↓
8 Servers

while still having an architecture that effectively behaves like:

"This user belongs to Server A."

That undermines the benefits of horizontal scaling.

Signals that you may have this gap

• Users experience session loss after deployments

• Requests behave differently depending on which server receives them

• Scaling requires special load balancer behavior

• Server replacement causes user state to disappear

• Failover is difficult

• Autoscaling introduces unexpected application behavior

The important architectural question is:

What state belongs to the request, and what state belongs to the system?

That distinction becomes increasingly important as systems scale.

6. Absence of Circuit Breakers

Modern applications rarely operate alone.

They call:

• Payment gateways

• Identity providers

• Banks

• Market data providers

• Email services

• Notification systems

• AI APIs

• Shipping providers

• Other internal services

Now imagine a downstream service becomes slow.

Your application continues calling it.

Those calls start waiting.

More users arrive.

More requests wait.

Threads and connections are consumed.

Retries may increase the load further.

The result can become a cascading failure.

Third Party Slow
       |
       v
Requests Wait
       |
       v
Connection Pool Exhausted
       |
       v
Requests Queue
       |
       v
Application Slows
       |
       v
More Timeouts
       |
       v
More Retries
       |
       v
System Degradation

AWS describes circuit breakers as a way to stop repeatedly calling a dependency that is failing, while Microsoft similarly distinguishes circuit breakers from retries: retries attempt recovery from transient failures, while circuit breakers prevent repeated calls when failure is persistent.

Why it becomes dangerous

A dependency failure should ideally remain a dependency failure.

It should not automatically become:

Dependency failure
        ↓
Application failure
        ↓
Platform failure
        ↓
Business outage

Signals that you may have this gap

• External service timeouts cause application wide latency

• Requests continue accumulating during dependency failures

• Retry storms occur

• Thread or connection pools become exhausted

• One failing service affects unrelated features

• There is no defined degraded mode

The deeper architectural question is:

What happens inside our system when a dependency stops responding?

7. Raw SQL Vulnerabilities

SQL itself is not the problem.

Direct SQL can be perfectly valid and appropriate.

The problem appears when applications construct SQL using untrusted input without appropriate parameterization and validation.

For example:

query =
"SELECT * FROM users WHERE id = '" + userId + "'";

Now application input has become part of the SQL statement itself.

This creates an injection risk.

OWASP specifically recommends defensive database practices and treats application layer injection prevention as a distinct security concern.

An important distinction

The architecture gap here is sometimes described as:

"We use raw SQL."

That is too broad.

Raw SQL is not inherently insecure.

The real concern is:

Untrusted Input
      +
Unsafe Query Construction
      =
Injection Risk

Parameterized queries, safe query construction, input validation, and appropriate access controls matter more than whether the application uses an ORM.

An ORM can reduce certain classes of risk, but using an ORM does not automatically make an application secure.

Signals that you may have this gap

• SQL queries are constructed using string concatenation

• User input directly enters query strings

• Database permissions are overly broad

• SQL security practices vary between teams

• There is no standard data access layer

• Security testing repeatedly finds injection risks

The architectural question is:

Where is the boundary between application input and database execution?

8. Unbuffered Database Read and Write

The database is often the center of an application.

That makes it tempting to send everything directly to it.

A checkout request arrives.

The application reads several records.

Then writes several records.

Another checkout arrives.

Then another.

Soon hundreds or thousands of concurrent requests are competing for the same database resources.

Request 1 ──┐
Request 2 ──┤
Request 3 ──┤
Request 4 ──┼──> Database
Request 5 ──┤
Request 6 ──┤
Request N ──┘

The database eventually becomes the bottleneck.

Why it becomes dangerous

A database has finite resources.

Those resources include:

• CPU

• Memory

• Connections

• Disk I/O

• Locks

• Buffer cache

• Query execution capacity

• Transaction capacity

If every request requires immediate database interaction, traffic growth can translate directly into database pressure.

This is particularly important for transaction heavy systems.

A sudden checkout spike can turn into database contention rather than simply higher application traffic.

Signals that you may have this gap

• Database connections frequently reach their limit

• Lock contention increases under load

• Write latency rises during traffic spikes

• Read traffic competes with critical writes

• Application servers spend significant time waiting for database operations

• The database is consistently the first component to saturate

The architectural question is:

Does every piece of work need to reach the primary database immediately?

That question is especially important when designing high throughput systems.

9. Zero Log Visibility

An application can be perfectly designed on paper and still be extremely difficult to operate.

Production tells you what actually happened.

Without useful logs, metrics, traces, and monitoring, engineers are forced to reconstruct incidents from incomplete information.

Imagine receiving this alert:

Payment failure rate increased.

Now ask:

Which API?
Which customer?
Which region?
Which payment provider?
Which release?
Which dependency?
Which error?
When did it start?
How many requests?
Which requests failed?
What happened immediately before the failure?

If the system cannot answer those questions, debugging becomes guesswork.

OWASP's cloud security guidance emphasizes logging and monitoring for understanding system behavior and investigating security incidents.

Modern secure design guidance also treats observability as something that should be designed into the system rather than added only after incidents occur.

Why it becomes dangerous

Poor visibility increases:

• Mean time to detect

• Mean time to diagnose

• Mean time to recover

It also makes capacity planning and performance analysis harder.

A production system is not just:

Code + Infrastructure

It is:

Code
+
Infrastructure
+
Telemetry
+
Operational Knowledge

Signals that you may have this gap

• Engineers SSH into servers to investigate incidents

• Logs exist on individual machines

• Logs cannot be correlated across services

• Production errors lack request identifiers

• There are no useful latency metrics

• Teams discover incidents through customer complaints

• Nobody can explain what changed before an outage

The architectural question is:

Can we understand what the system is doing while it is doing it?

10. Amateur Prompt Wrapper Layouts

AI applications introduce another architectural layer.

At first, the implementation may be extremely simple:

User Prompt
     |
     v
LLM API
     |
     v
Response

That can be perfectly reasonable for an experiment.

The problem begins when the same architecture becomes the foundation of a production application.

Consider an AI workflow that performs:

User Request
     ↓
Prompt Construction
     ↓
LLM
     ↓
Response
     ↓
Business Logic
     ↓
Database

What happens when the model:

• Returns invalid JSON?

• Changes the expected structure?

• Times out?

• Returns incomplete information?

• Produces an unexpected value?

• Uses more tokens than expected?

• Returns a response that downstream code cannot process?

A basic API wrapper may not have an answer.

Why this is an architecture problem

An LLM is a probabilistic component.

Traditional application components generally operate around deterministic contracts.

That creates a boundary problem.

Your application may expect:

{
  "customer_id": "123",
  "risk": "low"
}

But the model may return:

The customer appears to have a relatively low risk profile.

The response may be semantically useful to a human while being structurally unusable by the application.

Signals that you may have this gap

• AI responses are passed directly into business logic

• There is no structured output validation

• Invalid model responses can break workflows

• Retry behavior is undefined

• Provider failures are not handled explicitly

• Prompt changes are made without regression testing

• Model or provider changes can silently alter application behavior

• AI costs are not bounded

• There is no fallback when the model is unavailable

The architectural question is:

What contract exists between the probabilistic AI component and the deterministic software around it?

This is becoming one of the important architecture questions for modern AI applications.

The Common Pattern Behind All 10 Gaps

These problems look unrelated.

They are not.

Look at them together.

There is a common theme.

The system has not clearly defined its boundaries.

Boundaries around:

Components
Dependencies
Data
Configuration
State
Failures
Traffic
Security
Observability
AI behavior

Once those boundaries become unclear, problems start crossing them.

A database problem becomes an application problem.

An API problem becomes a user experience problem.

A third party outage becomes a platform outage.

A configuration mistake becomes a security incident.

An AI response becomes a business logic failure.

That is the real architecture problem.

Architecture Is About More Than Components

When engineers discuss architecture, conversations often begin with:

"Should we use Kafka?"

"Should we use Redis?"

"Should we use microservices?"

"Should we use Kubernetes?"

"Should we use PostgreSQL?"

These are useful questions.

But they are not the first questions.

A better architecture discussion starts with:

What outcome are we trying to produce?

What workloads exist?

What are the critical paths?

What can fail?

What must remain available?

What must be strongly consistent?

What can be asynchronous?

What data will grow?

What needs to scale independently?

What needs to be observable?

What happens when dependencies fail?

What happens when traffic increases?

What happens when the system behaves unexpectedly?

Technology choices should follow those answers.

Not the other way around.

A Simple Architecture Gap Review

You can use these questions as a first pass over an existing system.

Coupling

Can one feature change without unexpectedly affecting unrelated features?

Communication

Which operations genuinely need synchronous execution?

Configuration

Can environments and secrets be managed independently from application code?

Data

Will the database access patterns remain efficient as data grows?

State

Can application instances be added or removed without losing important user state?

Failure

What happens when an external dependency becomes slow or unavailable?

Security

Can untrusted input cross into sensitive systems without appropriate controls?

Capacity

What happens when database traffic increases by 10x?

Observability

Can engineers understand an incident without guessing?

AI

What happens when an AI component returns an unexpected response?

If the answer to any of these questions is unclear, you may have an architecture gap worth investigating.

The Most Dangerous Gaps Are Often Invisible

One of the biggest mistakes in architecture reviews is looking only for things that are already broken.

A better approach is to look for things that will become broken under a changed condition.

For example:

More Users
      ↓
More Requests
      ↓
More Database Load

Or:

More Dependencies
      ↓
More Failure Modes
      ↓
More Complex Failure Propagation

Or:

More Data
      ↓
Different Query Characteristics
      ↓
Different Performance Profile

Or:

More AI Usage
      ↓
More Probabilistic Behavior
      ↓
More Need for Explicit Contracts

Architecture is therefore not just about how the system behaves today.

It is about how the system behaves when its environment changes.

Architecture Gaps Become Business Gaps

Eventually, technical problems become business problems.

A slow database can become:

Slow checkout.

A dependency failure can become:

Failed payment.

Poor observability can become:

Longer outage.

Tight coupling can become:

Slower product releases.

Poor scaling architecture can become:

Lost customers during traffic spikes.

Hardcoded secrets can become:

A security incident.

Weak AI architecture can become:

Incorrect business decisions.

That is why architecture deserves business level attention.

The question is not:

"Is our architecture elegant?"

The better question is:

"Can our architecture reliably produce the business outcome we need as the system changes?"

Final Takeaway

A software system rarely becomes fragile because of one terrible architectural decision.

It usually becomes fragile through a collection of small decisions that were acceptable at the time.

The warning signs are often visible long before the outage.

Look for:

Tight coupling
Synchronous chokeholds
Configuration leakage
Poor data access
Stateful infrastructure
Weak failure isolation
Unsafe database boundaries
Database saturation
Poor observability
Weak AI contracts

These are not merely engineering inconveniences.

They are signals that the system may not have clear boundaries around change, scale, state, security, failure, data, and behavior.

And that is where architecture becomes important.

Good architecture is not about adding more technology.

It is about creating clear boundaries so the system can change, scale, fail, and recover without taking everything else down with it.

What comes next

Identifying the gap is only the first step.

The next question is:

How do you fix it?

In the next Think in Systems edition, I will take these architecture gaps from diagnosis to intervention and look at the patterns, design decisions, and tradeoffs that can address them.

Because finding the gap is useful.

Fixing the system is what creates the outcome.

Think in Systems

Complex problems. Simple systems. Better outcomes.

Think in Systems is my weekly newsletter for people who build and lead across technology, business, AI, product, and engineering.

I use practical frameworks to move from:

Problem → System → Constraint → Intervention → Outcome

Order. Execution. Trade. Transaction. Position.

They are often used together.

They are also often confused.

That confusion becomes a problem when designing financial software because each represents a different point in the lifecycle of an investor's activity.

A simple mental model is:

INTENTION
   |
   v
ORDER
   |
   v
EXECUTION
   |
   v
TRADE
   |
   v
POSITION

A transaction is a broader concept that can represent a financial movement or event, depending on the system and accounting model.

Let's separate them.

1. Order

An order represents an instruction to buy or sell an instrument.

Example:

Instrument: ABC
Side: Buy
Quantity: 100
Order type: Limit
Limit price: ₹500

The important word is:

Instruction.

The customer is saying:

"I want to buy 100 shares of ABC at this price."

That does not mean the purchase has happened.

The order may be:

Created
Validated
Rejected
Accepted
Partially filled
Filled
Cancelled
ExpiredAn order therefore represents intent and lifecycle state.

2. Execution

An execution represents an actual fill against an order.

Suppose the customer submits:

Buy 100 ABC

The market may execute:

40 shares at ₹499
30 shares at ₹500
30 shares at ₹501

That creates three executions.

Order
100 shares
     |
     +---- Execution 1
     |     40 @ ₹499
     |
     +---- Execution 2
     |     30 @ ₹500
     |
     +---- Execution 3
           30 @ ₹501

The order is therefore not necessarily equal to one execution.

This distinction becomes important when modelling order state, average execution price and downstream position updates.

3. Trade

A trade represents the economic result of an execution between counterparties.

In a brokerage platform, terminology can vary by market and system design.

But conceptually:

Order
  ↓
Execution
  ↓
Trade

The trade becomes part of the downstream financial lifecycle.

It can contribute to:

• Position updates

• Settlement

• Ledger entries

• Reporting

• Portfolio calculations

• Reconciliation

This is why a trade should not simply be treated as another name for an order.

4. Transaction

Transaction is the broadest term in this discussion.

A transaction can represent a financial movement or business event.

Examples might include:

Cash deposit
Cash withdrawal
Buy transaction
Sell transaction
Fee
Tax
Dividend
Interest
Transfer
Adjustment
Settlement movement

So:

Every trade related event may participate in
a broader transaction lifecycle.

But not every transaction is a trade.

For example:

A customer deposits ₹100,000 into their brokerage account.

That is a financial transaction.

No security was traded.

5. Position

A position represents the customer's current holding or exposure.

Suppose the customer executes:

Buy 100 ABC

Their position might become:

ABC
Quantity: 100

Then they sell:

40 ABC

The resulting position might become:

ABC
Quantity: 60

So position is fundamentally about current state.

The order describes what was requested.

The execution describes what was filled.

The trade represents the resulting economic activity.

The position represents the resulting holding.

6. One complete example

Let's follow one order.

The customer submits:

Buy 100 ABC
Limit price ₹500

Step 1

An order is created.

ORDER
Buy 100 ABC

Step 2

The order passes validation and risk checks.

ORDER
Accepted

Step 3

The order is routed to the relevant execution venue.

Step 4

The market fills:

40 @ ₹499
60 @ ₹500

There are now two executions.

Step 5

The resulting trade records are captured.

Step 6

The position changes:

ABC
+100 shares

Step 7

The financial system records the appropriate financial movements.

Step 8

Downstream systems update:

Portfolio
Reporting
Notifications
Analytics
Reconciliation

The complete lifecycle is therefore:

Customer intention
       ↓
      Order
       ↓
   Risk checks
       ↓
    Routing
       ↓
   Execution
       ↓
     Trade
       ↓
    Position
       ↓
 Financial records
       ↓
 Portfolio / Reporting

7. Why the distinction matters architecturally

These concepts often become separate data models because they answer different questions.

This separation also helps when handling failures.

Imagine the customer submits an order.

The application times out.

The customer retries.

The first request may already have reached the downstream trading system.

Now the system needs to determine whether an order already exists and whether it has been executed.

That is one reason idempotency and durable order state matter in financial systems.

8. Order versus position

This distinction is especially important.

An order is event and intent oriented.

A position is state oriented.

For example:

Order 1
Buy 100

followed by:

Order 2
Sell 40

can result in:

Position
60

The position cannot tell you everything that happened.

The order history can.

This means a production system generally needs both:

Historical records, and Current state

9. Where these concepts sit in the architecture

A simplified model looks like:

             ORDER DOMAIN
                  |
                  v
                Order
                  |
                  v
                Risk
                  |
                  v
                 OMS
                  |
                  v
          Execution Venue
                  |
                  v
            EXECUTION
                  |
                  v
               TRADE
             /       \
            v         v
      POSITION      LEDGER
            |         |
            +----+----+
                 |
                 v
             PORTFOLIO

This is intentionally simplified.

Different platforms can combine or separate these responsibilities differently.

The important part is understanding the semantic boundaries.

10. A useful rule

When designing a financial system, ask:

Am I representing what someone wanted, what actually happened, or the current state produced by what happened?

That question often tells you which domain object you need.

Wanted
  ↓
Order

Happened
  ↓
Execution / Trade

Current state
  ↓
Position

Financial movement
  ↓
Transaction / Ledger

Once these concepts are clear, designing the services around them becomes much easier.

Continue the series

Next we can go deeper into:

How Does an Online Brokerage Order Actually Flow?

That article will connect these concepts into a complete lifecycle from customer order submission through validation, risk checks, routing, execution, trade capture, position updates and reconciliation.

For deeper first person architecture decisions and tradeoffs,

subscribe to Think in Systems.

Complex problems. Simple systems. Better outcomes.

A customer opens an account.

They add money.

They search for a security.

They place an order.

The order gets executed.

Their portfolio changes.

But behind that apparently simple journey is a collection of systems responsible for identity, accounts, funding, order management, risk, execution, positions, portfolios, financial records, market data, notifications and reconciliation.

A brokerage platform is therefore not a single application.

It is a financial system made up of multiple cooperating systems with different responsibilities and correctness requirements.

This article explains the major components and how data flows between them.

This is a reference architecture. Actual implementations vary by market, broker, asset class, regulatory environment and operating model.

1. The high level architecture

A simplified brokerage platform can be represented as:

                     CUSTOMER
                        |
                        v
                +---------------+
                | Mobile / Web  |
                +---------------+
                        |
                        v
                +---------------+
                | API Gateway   |
                +---------------+
                        |
         +--------------+--------------+
         |              |              |
         v              v              v
    Identity &       Account        Portfolio
    KYC Services     Services        Services
                        |
                        v
                +---------------+
                | Order Service |
                +---------------+
                        |
                        v
                +---------------+
                | Risk Checks   |
                +---------------+
                        |
                        v
                +---------------+
                | OMS           |
                +---------------+
                        |
                        v
              +---------------------+
              | Broker / Exchange   |
              | Connectivity        |
              +---------------------+
                        |
                        v
                   EXECUTION
                        |
                        v
                +---------------+
                | Trade Capture |
                +---------------+
                        |
            +-----------+-----------+
            |           |           |
            v           v           v
       Positions      Ledger     Portfolio
            |           |           |
            +-----------+-----------+
                        |
                        v
                Reconciliation

This is intentionally simplified.

A production platform will usually have additional services for market data, reference data, notifications, reporting, compliance, analytics, observability and operational workflows.

2. Customer and presentation layer

The customer interacts with the brokerage through applications such as:

• Mobile applications

• Web applications

• APIs

The presentation layer should not directly own financial business logic.

For example, the mobile application should not independently decide whether an order is valid.

It should request that decision from the appropriate backend service.

This keeps important business rules inside controlled services rather than distributing them across clients.

3. Identity and KYC

Before a customer can trade, the platform needs to establish who the customer is and what they are permitted to do.

Typical responsibilities include:

• User identity

• Authentication

• KYC status

• Account status

• Regulatory information

• Customer classification

• Restrictions

The exact responsibilities depend heavily on the jurisdiction and business model.

This service is part of the onboarding system, but its output affects downstream trading capabilities.

For example:

Customer
   |
   v
Identity
   |
   v
KYC
   |
   v
Account activation
   |
   v
Trading eligibility

The important architectural point is that identity and trading eligibility are related but different concerns.

4. Account service

A customer can have one or more financial accounts.

The account domain typically manages information such as:

• Account identity

• Account status

• Account type

• Base currency

• Trading permissions

• Linked funding relationships

• Regulatory attributes

The account becomes an important boundary for downstream operations.

For example, an order generally needs to be associated with a specific account.

5. Funding and cash management

A brokerage platform also needs to manage money moving into and out of the platform.

Typical flows include:

Bank
  |
  v
Payment / Banking Integration
  |
  v
Cash Account
  |
  v
Available Buying Power

The exact architecture varies significantly depending on whether the brokerage operates its own payment infrastructure, uses banking partners or integrates with another financial institution.

The important point is that cash movement and securities trading are related but distinct workflows.

A successful deposit does not mean that an equity order has been executed.

6. Order management

The order service receives the customer's trading instruction.

For example:

Buy
100 shares
ABC
Limit price: ₹500

The order is not yet a trade.

It is an instruction or intention to trade.

The platform needs to validate the request and maintain its lifecycle.

A simplified lifecycle might look like:

Created
   |
   v
Validated
   |
   v
Risk Checked
   |
   v
Submitted
   |
   v
Accepted
   |
   v
Partially Filled
   |
   v
Filled

Other states can include rejected, cancelled, expired or pending.

This is one reason order management becomes a distinct domain.

An order has a lifecycle.

A trade represents an execution.

They should not be treated as the same object.

7. Risk management

Before an order reaches the market, the platform may need to perform several checks.

Examples include:

• Available funds

• Available quantity

• Position limits

• Instrument restrictions

• Customer restrictions

• Exposure limits

• Trading permissions

• Regulatory checks

• Risk limits

A simplified flow is:

Order
  |
  v
Validation
  |
  v
Risk checks
  |
  +---- Rejected
  |
  v
Approved

The exact checks depend on the product and regulatory environment.

For high performance trading systems, some risk checks may need to happen directly in the critical order path. AWS describes similar patterns in low latency trading architectures where pre trade risk validation sits directly in the trading path.

8. Order Management System

The Order Management System, or OMS, coordinates order lifecycle management.

It may be responsible for:

• Maintaining order state

• Routing orders

• Managing modifications

• Managing cancellations

• Receiving execution updates

• Maintaining order history

• Connecting with broker or exchange adapters

The OMS does not necessarily perform every trading function itself.

Instead, it coordinates several parts of the order lifecycle.

A simplified model is:

Customer
   |
   v
Order Service
   |
   v
Risk
   |
   v
OMS
   |
   v
Broker / Exchange

Enterprise trading platforms commonly separate order management from execution and connectivity concerns. AWS reference architectures also show order management and broker or exchange connectivity as distinct responsibilities.

9. Broker and exchange connectivity

The OMS cannot simply send an internal order object directly to every market.

Different venues can expose different protocols, APIs and connectivity models.

An adapter layer can isolate those differences.

             OMS
              |
    +---------+---------+
    |         |         |
    v         v         v
 Adapter   Adapter   Adapter
    |         |         |
  Venue A   Venue B   Venue C

This abstraction becomes particularly important when a platform connects to multiple brokers, exchanges or execution venues.

10. Execution and trade capture

Once an order reaches the relevant execution venue, it may be:

• Accepted

• Rejected

• Partially executed

• Fully executed

A single order can therefore produce multiple executions.

For example:

Order
100 shares
    |
    +---- Execution 1: 40
    |
    +---- Execution 2: 35
    |
    +---- Execution 3: 25

The total quantity executed is 100.

The order and executions are therefore separate concepts.

The execution becomes the basis for creating trade records and updating downstream financial state.

11. Position management

A position represents the customer's current holding or exposure.

For example:

ABC
Quantity: 100
Average price: ₹500

A position is not simply another copy of an order.

The order describes what the customer asked the system to do.

The execution describes what actually happened.

The position represents the resulting holding.

Conceptually:

Order
  |
  v
Execution
  |
  v
Trade
  |
  v
Position

The actual calculation can become much more complex when there are multiple executions, corporate actions, transfers, derivatives or different accounting treatments.

12. Portfolio service

The portfolio layer aggregates financial state for the customer.

It may provide:

• Holdings

• Cash

• Portfolio value

• Unrealized profit and loss

• Realized profit and loss

• Asset allocation

• Performance

• Exposure

The portfolio view is therefore derived from multiple underlying domains.

Positions
Cash
Corporate Actions
Prices
Transactions
      |
      v
Portfolio

This is why a portfolio service should not become the system of record for everything.

It is primarily a view of financial state assembled from underlying records.

13. Financial ledger

The financial ledger records financial movements according to the accounting model of the platform.

Examples can include:

• Cash movements

• Fees

• Charges

• Settlements

• Adjustments

• Transfers

• Other financial entries

The ledger is different from the operational order database.

An order database answers:

What happened to this order?

A ledger answers:

What financial movement was recorded?

Keeping these concepts separate is important because the lifecycle and correctness requirements are different.

14. Market data

The customer also needs information about the market.

Market data can include:

• Prices

• Bid and ask

• Volume

• Trades

• Order book information

• Instrument reference data

A simplified flow is:

Exchange / Market Data Provider
              |
              v
       Market Data Gateway
              |
              v
       Normalization Layer
              |
              v
        Event Streaming
              |
       +------+------+
       |             |
       v             v
   Trading       Customer APIs
   Services          |
                     v
               Web / Mobile

Market data architecture can be significantly more complex depending on latency, market coverage and distribution requirements.

AWS describes market data architectures where real time sources are ingested, processed and distributed through streaming infrastructure and interfaces such as WebSockets or APIs.

15. Event streaming

A brokerage platform contains many events.

Examples:

OrderCreated
OrderAccepted
OrderRejected
OrderExecuted
TradeCreated
PositionUpdated
CashUpdated
PortfolioUpdated

These events can be distributed to other systems.

For example:

                 Order Service
                      |
                      v
                Event Stream
                      |
        +-------------+-------------+
        |             |             |
        v             v             v
   Notification   Portfolio     Analytics

Event streaming can reduce direct coupling between services.

But it does not eliminate the need for transactional correctness.

A critical financial record should not become correct merely because an event was successfully published.

The system still needs clear ownership of the underlying state.

16. Reconciliation

Financial systems cannot simply assume that every system always agrees.

Records can differ because of:

• Network failures

• Duplicate messages

• Delayed messages

• Partial processing

• External system failures

• Manual adjustments

• Data corrections

Reconciliation compares records across systems.

For example:

Broker Records | | compare v Internal Trade Records | | compare v Ledger | | compare v Positions

A mismatch becomes an operational exception that needs investigation.

Reconciliation is therefore not merely a reporting feature.

It is part of the control architecture of a financial platform.

17. Where the data lives

A modern brokerage platform usually has multiple categories of data.

Transactional data

Orders, accounts, trades and other operational records.

Financial records

Ledger and financial transactions.

Market data

Prices, quotes, trades and potentially order book information.

Reference data

Instruments, exchanges, currencies and other relatively stable reference information.

Analytical data

Historical events, customer analytics, reporting and business intelligence.

These workloads have different access patterns.

Trying to force every workload into one database usually creates unnecessary coupling.

18. The complete simplified data flow

Putting the major components together:

                     CUSTOMER
                        |
                        v
                Web / Mobile / API
                        |
                        v
                Identity / Account
                        |
                        v
                     Order
                        |
                        v
                Validation / Risk
                        |
                        v
                       OMS
                        |
                        v
             Broker / Exchange Adapter
                        |
                        v
                    Execution
                        |
                        v
                  Trade Capture
                        |
          +-------------+-------------+
          |             |             |
          v             v             v
      Position       Ledger       Portfolio
          |             |             |
          +-------------+-------------+
                        |
                        v
                 Reconciliation

At the same time:

Market Data Sources
        |
        v
Market Data Ingestion
        |
        v
Streaming / Distribution
        |
        +-------------> Trading Services
        |
        +-------------> Customer APIs
        |
        +-------------> Web / Mobile
        |
        +-------------> Analytics

This gives us two major flows:

Trading flow

Intent → Order → Risk → Execution → Trade → Position

Market data flow

Market → Ingestion → Processing → Distribution → Customer

And a third important control flow:

Financial control flow

Transactions → Ledger → Reconciliation

19. The most important architectural boundary

A useful way to think about the entire platform is to separate three questions.

What did the customer request?

Order

What actually happened in the market?

Execution and trade

What does the customer own now?

Position and portfolio

Then separately:

What financial movements were recorded?

Ledger

And:

Do our systems agree?

Reconciliation

Once these responsibilities are explicit, the architecture becomes easier to reason about.

20. Why this architecture matters

A brokerage platform is not difficult merely because it has many services.

The difficult part is that different parts of the system have different definitions of correctness.

An order can be accepted without being executed.

An order can be partially executed.

A trade can exist before a portfolio view reflects it.

Market data can be delayed while an order is being processed.

A customer request can time out even though the downstream system accepted the order.

A financial record can require reconciliation even when the application itself reported success.

These are architectural problems, not merely coding problems.

That is why a brokerage platform needs explicit boundaries between:

• Orders

• Executions

• Trades

• Positions

• Portfolio

• Ledger

• Market Data

• Reconciliation

The next articles will examine these domains individually.

Continue the WealthTech Architecture Series

Next:

Orders, Executions, Trades, Transactions and Positions: What's the Difference?

Understanding these concepts is essential before designing the services that manage them.

For deeper architectural reasoning, design tradeoffs and first person engineering perspectives, subscribe to Think in Systems.

Complex problems. Simple systems. Better outcomes.

Subscribe to Think in Systems

Imagine a stadium.

There are 100,000 people outside.

There are ten entrances.

If everyone uses the same entrance, you have a problem.

The other nine entrances may be empty.

The first entrance becomes crowded.

People wait.

The system slows down.

A load balancer solves a similar problem for software systems.

Instead of sending every request to one server, it distributes requests across multiple servers.

That is the basic idea.

But real load balancing is much more interesting.

Why do we need multiple servers?

Suppose your application has one server.

Initially, this might work perfectly.

Then traffic grows.

100 users.

1,000 users.

10,000 users.

Eventually the server reaches its capacity.

You have two options.

Make the server bigger.

Or add more servers.

The second approach is called horizontal scaling.

Now traffic can be distributed.

What does the load balancer actually do?

At a basic level:

Client
  ↓
Load Balancer
  ↓
Application Server

The client does not necessarily need to know which application server handled the request.

The load balancer becomes the traffic entry point.

It receives the request.

It decides where the request should go.

It forwards the request.

The server processes it.

The response comes back.

But how does it choose a server?

This is where algorithms come in.

Round Robin

The simplest approach.

It cycles through servers.

Simple.

But it assumes servers have similar capacity and requests have similar cost.

That assumption is not always true.

Weighted Round Robin

Suppose:

Server A has 8 CPU cores.

Server B has 4.

Server C has 2.

You might want:

Server A → 50%
Server B → 30%
Server C → 20%

The load balancer can assign traffic based on weights.

Least Connections

Instead of counting requests, the load balancer looks at active connections.

For example:

Server A → 100 connections
Server B → 30 connections
Server C → 50 connections

A new request might go to Server B.

This can be useful when requests have different processing times.

What happens when a server dies?

This is one of the most important jobs of a load balancer.

Suppose:

Server A → Healthy
Server B → Healthy
Server C → Failed

The load balancer should stop sending traffic to Server C.

How does it know?

Health checks.

Health checks

The load balancer periodically checks servers.

For example:

GET /health

A healthy response might be:

200 OK

If the server repeatedly fails health checks, it can be removed from the traffic pool.

This gives us:

The user may never know that Server C failed.

That is one of the benefits of redundancy.

But health checks are not magic

Imagine the server responds:

200 OK

But its database connection pool is exhausted.

Is the server actually healthy?

This is where health check design becomes important.

A shallow health check may only verify:

"Is the process alive?"

A deeper health check may verify critical dependencies.

But checking every dependency can also create problems.

If the database has a temporary issue, suddenly every server might appear unhealthy.

So health checks themselves need thoughtful design.

Layer 4 and Layer 7 load balancing

Load balancers can operate at different networking layers.

Layer 4

Layer 4 works primarily with network information such as:

• IP address
• TCP
• Port

It does not need to understand the application request deeply.

Layer 7

Layer 7 understands application level information such as:

• HTTP
• URL path
• Headers
• Cookies
• Hostname

For example:

/api/orders → Order Service

/api/payments → Payment Service

/api/users → User Service

This makes Layer 7 routing much more powerful.

Load balancing is not only about traffic

It can also provide:

• Health checking
• TLS termination
• Routing
• Connection management
• Failover
• Rate limiting in some architectures
• Session handling
• Service discovery integration

The exact capabilities depend on the architecture and product.

What happens during a traffic spike?

Suppose normal traffic is:

1,000 requests/sec

Then a marketing campaign starts.

Traffic becomes:

10,000 requests/sec

If you have only one server, it may struggle.

With multiple servers:

             Load Balancer
          /    /    |    \
         ↓    ↓     ↓     ↓
        S1   S2    S3    S4

Traffic can be distributed across the fleet.

But here is an important systems thinking lesson:

A load balancer does not make an unlimited system scalable.

It only moves the constraint.

The hidden bottleneck

Suppose you have:

Load Balancer
      ↓
10 Application Servers
      ↓
One Database

The application layer can scale.

The database may not.

You could increase the application servers from 10 to 100.

But if all 100 servers depend on one database, the database may become the constraint.

This is why architecture needs systems thinking.

Scaling one component does not automatically scale the system.

The real model

Think about the entire path:

Every layer has:

• Capacity

• Latency

• Failure modes

• Dependencies

• Scaling characteristics

The system's behavior emerges from all of them.

The deeper lesson

When you learn load balancing, don't memorize:

"Round Robin distributes requests."

Ask:

Why do we need distribution?

What happens if one server fails?

What determines whether a server is healthy?

What happens when traffic becomes uneven?

What happens if the database becomes the bottleneck?

What happens when a request takes much longer than another request?

Those questions move you from technology knowledge toward architecture thinking.

Think in Systems

A load balancer is not simply a networking component.

It is part of a larger system designed to manage capacity, availability and failure.

That is the mindset I explore in Think in Systems.

Complex problems. Simple systems. Better outcomes.

When people hear the word "system", they often think about software.

A backend.

A database.

An API.

A collection of microservices.

But a system is much broader than that.

A system is a set of connected parts that interact with each other to produce an outcome.

That definition works for software.

It also works for businesses.

Teams.

Markets.

AI applications.

Sales processes.

Even something as simple as a restaurant.

The important word is not "parts".

It is connected.

Because the behavior of a system comes not only from what its individual parts do.

It comes from how those parts interact.

Think about a food delivery application

A customer opens an application.

They search for a restaurant.

They select food.

They place an order.

They make a payment.

The restaurant accepts the order.

A delivery partner is assigned.

The food is prepared.

The food is delivered.

From the customer's perspective, this looks like one action:

"Order food."

But behind that action is a system.

Each component has a responsibility.

But none of them produces the final outcome alone.

The outcome emerges from their interaction.

A system has parts

Let's start with the simplest model.

System
│
├── Components
├── Relationships
├── Inputs
├── Processes
├── Constraints
└── Outputs

Components

The things that make up the system.

In software:

• Applications

• Services

• Databases

• Queues

• Users

• External systems

Relationships

How those components interact.

For example:

Inputs

What enters the system.

Examples:

• User request

• Payment

• Market data

• Customer information

Processes

What the system does with those inputs.

Constraints

What limits the system.

Examples:

• Database capacity

• Network latency

• Regulatory rules

• Budget

• Human decision making

Outputs

What the system ultimately produces.

Examples:

• Successful payment

• Completed order

• Customer account

• Investment position

But here is where system thinking becomes interesting

Suppose your application is slow.

What would you investigate?

A developer might immediately look at the application code.

But the problem may not be inside the application.

Maybe the database is overloaded.

Maybe the API is waiting for another service.

Maybe a third party API is slow.

Maybe the application is making unnecessary calls.

Maybe a queue is backed up.

Maybe the system is performing expensive synchronous work.

So instead of asking:

"Which component is broken?"

System thinking asks:

"What is producing this outcome?"

That is a very different question.

Components do not tell the whole story

Consider this system:

It looks simple.

Now imagine:

The API receives 10,000 requests per second.

The application processes them.

The database can handle only 2,000 writes per second.

The database becomes the constraint.

The application may appear slow.

But the application is not necessarily the root cause.

The system is constrained by the database.

This gives us an important principle:

The visible problem is not always the system producing the problem.

A system is about relationships

Imagine two teams.

Team A has ten engineers.

Team B has ten engineers.

Both teams have similar technical skills.

But Team A needs five approvals before production deployment.

Team B needs one.

Which team can move faster?

The answer may have little to do with engineering capability.

The difference may be the system around the engineers.

This is why systems thinking is useful beyond software engineering.

The system boundary matters

You also need to decide:

"What exactly am I studying?"

Suppose your payment fails.

You could study only the payment service.

Or you could study:

Customer
 ↓
Checkout
 ↓
Payment Gateway
 ↓
Bank
 ↓
Payment Processor
 ↓
Merchant System

Your system boundary determines what you can see.

If your boundary is too small, you may miss the real constraint.

If it is too large, the analysis becomes unnecessarily complicated.

Good system design therefore starts with defining the boundary.

A practical model

When I start looking at a system, I use:

Notice something important.

The intervention comes after understanding the system.

Not before.

The beginner mistake

A common mistake is:

Problem
 ↓
Solution

For example:

"Application is slow."

Solution:

"Add Redis."

But why is it slow?

Maybe caching helps.

Maybe it does not.

Perhaps the real issue is database contention.

Perhaps network calls dominate latency.

Perhaps an external dependency is slow.

Technology should come after understanding the system.

The engineering perspective

As you become more experienced, architecture becomes less about memorizing technologies.

It becomes more about answering questions.

Where is the state?

Who owns it?

What happens when something fails?

Where is the bottleneck?

What must be strongly consistent?

What can eventually become consistent?

What happens when traffic increases?

What happens when dependencies become unavailable?

What happens when the system does not know whether an operation succeeded?

These questions are systems questions.

A simple exercise

Take any application you use.

A banking application.

Food delivery.

Instagram.

An eCommerce website.

Draw this:

User
 ↓
 ?
 ↓
 ?
 ↓
 ?
 ↓
Outcome

Then fill in the components.

After that, ask:

1. What are the inputs?

2. What are the outputs?

3. Which components depend on each other?

4. Where can the system fail?

5. What is the most likely constraint?

6. What must always be correct?

7. What can eventually become consistent?

You have just started doing system design.

The deeper idea

System design is not primarily about drawing boxes.

It is about understanding relationships, constraints and outcomes.

Once you understand that, technologies become easier to reason about.

You stop asking:

"Should I use Kafka?"

And start asking:

"Do I need asynchronous event distribution here?"

You stop asking:

"Should I use Redis?"

And start asking:

"Do I have a low latency access problem that should be separated from my primary data store?"

That shift is the beginning of systems thinking.

Think in Systems

I write about software systems, AI systems, business systems and the thinking behind better decisions.

Complex problems. Simple systems. Better outcomes.

Subscribe to Think in Systems for the deeper weekly breakdown.