Sistem Entegrasyonu: POS, E-ticaret, Banka ve E-fatura Rehberi

Integration Architecture Fundamentals

The backbone that ties otherwise disconnected systems together

System integration architecture is the technical scaffolding that lets software systems, each built to run on its own, share data and processes. In practice it comes down to a handful of moving parts:

Architectural Components

• Source systems: Systems that generate data (POS, e-commerce, production)
• Target systems: Systems that consume data (ERP, accounting, reporting)
• Integration layer: Transporting, transforming, and managing data between systems
• Data formats: Standards such as JSON, XML, CSV, EDIFACT
• Communication protocols: HTTP/HTTPS, FTP/SFTP, AS2, AMQP, MQTT

Integration Topologies

1. Point-to-Point

Each system connects directly to another. Fine when you only have a few systems, but it gets out of hand fast as the count grows: N systems mean N*(N-1)/2 connections to look after.

2. Hub-and-Spoke

All systems connect to a central hub (middleware). Management gets simpler, but that hub turns into a single point of failure. If the center goes down, everything stops at once.

3. Enterprise Service Bus (ESB)

Handles message routing, transformation, and orchestration over a distributed architecture. This is where large enterprise systems tend to land.

4. Event-Driven Architecture (EDA)

Systems publish events and subscribe to each other’s. You get wide-scale scalability and loose coupling.

API Integration: REST, SOAP, GraphQL

Most of modern integration is built on top of APIs

An API is the interface systems use to talk to each other programmatically. Which type you reach for depends on the scenario:

REST API

REST is a stateless style built on top of HTTP. It’s the API type you’ll run into most often today.

• HTTP methods: GET (read), POST (create), PUT/PATCH (update), DELETE (delete)
• Data format: Usually JSON, sometimes XML
• Advantages: Simplicity, widespread support, easy debugging
• Use cases: E-commerce, mobile applications, SaaS integrations

SOAP API

SOAP is an XML-based protocol with strict rules. It’s still around in enterprise systems and banking.

• Data format: XML (defined by WSDL)
• Security: Advanced security with WS-Security
• Advantages: Transaction support, ACID compliance, strict security
• Use cases: Banking integrations, enterprise ERP systems

GraphQL

A query language and runtime from Facebook where the client decides exactly which fields it wants back.

• Feature: Single endpoint, flexible queries
• Advantages: Prevents over-fetching/under-fetching, ease of version management
• Use cases: Modern frontend applications, mobile APIs

API Integration Best Practices

• Always use HTTPS, never HTTP
• Authenticate using API keys or OAuth 2.0
• Prevent abuse by implementing rate limiting
• Ensure backward compatibility with version management (v1, v2)
• Return comprehensive error codes and messages
• Keep API documentation up to date (OpenAPI/Swagger)

Middleware Architecture

Middleware is the bridge that keeps traffic between systems in order

Middleware is the software layer that sits between source and target systems and takes on data transformation, routing, and orchestration. So why does it matter?

Middleware Advantages

• Loose Coupling: Systems do not need to know each other directly
• Data transformation: Translation between different formats (JSON – XML – CSV)
• Protocol translation: Transition between HTTP – SFTP – AS2 – MQ
• Queue management: Asynchronous processing and load balancing
• Error management: Retry, dead letter queue, circuit breaker
• Monitoring and logging: Centralized observation point

Middleware Types

1. Message Broker

Manages the message queue. Systems produce (producer) and consume (consumer) messages. Apache Kafka, RabbitMQ, and Azure Service Bus fall into this camp.

2. Enterprise Service Bus (ESB)

Handles message routing, transformation, orchestration, and protocol translation in one place. Think MuleSoft, IBM Integration Bus, WSO2.

3. iPaaS (Integration Platform as a Service)

A cloud-based integration platform. Ready-made connectors, a visual designer, and managed infrastructure come in the box. Zapier, Make (Integromat), Boomi, and Workato are examples.

Middleware Selection Criteria

• Scale and complexity of your systems
• Technical team competency
• On-premise vs. cloud preference
• Budget and licensing model
• Number and quality of pre-built connectors
• Monitoring and debugging capabilities

Real-time vs. Batch Integration

Getting the timing right is what makes or breaks an integration

One of the make-or-break calls in integration architecture is deciding when data moves. There are two basic approaches:

Real-time Integration

Data moves the instant an event happens.

Advantages:

• Instant data consistency
• Fast business processes
• Improved user experience

Disadvantages:

• Increased system load
• Risk of data loss during target system outages
• More complex error management

Use Cases:

• POS sales landing in the ERP the moment they happen
• E-commerce order notifications
• Stock level alerts
• Payment processing

Batch Integration

Data moves in bulk at set intervals (hourly, daily).

Advantages:

• Reduces system load
• Error tolerance (retry capability)
• Efficient for large data volumes
• Simpler error management

Disadvantages:

• Data latency
• Temporary inconsistency

Use Cases:

• Daily stock synchronization
• Accounting closing processes
• Reporting data updates
• Master data transfer

Hybrid Approach

Most enterprise systems end up running both side by side:

• Critical transactions (orders, payments) are real-time
• High data volumes (reporting, archiving) are batch
• Near real-time is an intermediate solution (e.g., 5-15 minute intervals)

Webhook and Event-Driven Patterns

Webhooks are the workhorse of event-driven integration

A webhook is a mechanism that fires an HTTP POST to another system the moment an event happens in one system. Instead of polling, it pushes the data to you.

How Webhooks Work

1. The target system creates a URL (endpoint) and registers it with the source system
2. The defined event occurs in the source system (e.g., a new order)
3. The source system sends an HTTP POST request to the target URL
4. The target system receives the request, processes it, and returns a confirmation (200 OK)

Webhook Advantages

• Resource efficiency: Communication only when an event occurs instead of constant polling
• Instant notification: Real-time integration
• Simplicity: Standard HTTP protocol

Webhook Challenges

• Delivery guarantee: What happens if the target system does not respond?
• Ordering: Do messages arrive in sequence?
• Idempotency: What if the same message arrives multiple times?
• Security: Webhook requests must be verified

Webhook Best Practices

• Use a unique ID for every webhook request (idempotency key)
• Perform webhook verification with an HMAC signature
• Set up a retry mechanism for failed deliveries (exponential backoff)
• Store and monitor webhook logs
• Set timeout durations (e.g., 30 seconds)

Event-Driven Architecture Patterns

Event Sourcing

State changes are recorded as events, and the current state is rebuilt by replaying them. Ideal for audit trails and temporal queries.

CQRS (Command Query Responsibility Segregation)

Read and write operations use separate models. Provides performance optimization and scalability.

Saga Pattern

Distributed transaction management. Used to keep things consistent in a microservices architecture.

EDI Standards and Use Cases

EDI is one of the older but still load-bearing pillars of B2B integration

EDI (Electronic Data Interchange) lets business partners swap electronic documents in a standard format. It predates modern APIs by decades, yet it’s still very much a must-have.

EDI Standards

EDIFACT (UN/EDIFACT)

An international standard developed by the United Nations. Common in European and international trade.

X12 (ANSI ASC X12)

A standard widely used in North America. Dominant in the US retail and healthcare sectors.

TRADACOMS

An older standard used in the UK retail sector.

Common EDI Document Types

• Purchase Order (ORDERS / 850): Purchase order
• Order Response (ORDRSP / 855): Order confirmation
• Shipping Notice (DESADV / 856): ASN (Advanced Shipping Notice)
• Invoice (INVOIC / 810): Commercial invoice
• Inventory Report (INVRPT / 846): Inventory status

EDI Communication Protocols

• AS2 (Applicability Statement 2): Secure EDI transfer over HTTP
• SFTP: Secure file transfer
• VAN (Value Added Network): Third-party EDI networks
• AS4: Modern alternative based on web services

EDI vs. API: Which and When?

• Choose EDI: When large retail chains, logistics firms, or B2B partners make it the mandatory standard
• Choose API: Modern SaaS integrations, flexible data needs, rapid development
• Hybrid approach: EDI for EDI partners, APIs for modern systems

Field Example: Omnichannel Retail Integration

Real Case (Unbranded)

Situation

A 45-branch retail chain with 8 systems to tie together: central ERP, 3 different POS brands, an e-commerce platform, bank POS, an e-invoice service, and a logistics partner. Daily transaction volume: 15,000+ sales.

Integration Architecture Decisions

1. Middleware selection: iPaaS solution chosen (ready-made connectors, visual design, managed infrastructure)
2. POS integration: Real-time API for data transfer to ERP at the moment of sale
3. E-commerce: Order notification via webhook, stock synchronization via batch (15-minute intervals)
4. Bank: Reconciliation via SOAP API, daily transfer to ERP via batch
5. E-invoice: Invoice creation and submission via real-time API
6. Logistics: Shipment notification via EDI (DESADV)

Result (Representative)

• Integration setup time: 12 weeks
• Daily transaction success rate: 99.7%
• Average data latency: POS-ERP 3 seconds, e-commerce stock 12 minutes
• Reduction in manual data entry: 85%
• Reconciliation time: Reduced from 2 business days to 2 hours

7 Most Common Mistakes in Integration Architecture

1. Failing to Plan for Error Scenarios

The “the system always works” assumption. Nobody decided what happens during a target system outage, a network error, or a timeout. So data goes missing or ends up inconsistent.

2. Not Ensuring Idempotency

Process the same message twice and you get duplicate records, for example the same order written to the ERP twice. Every message needs a unique ID and a duplicate check.

3. Insufficient Logging and Monitoring

Integration errors only surface once users complain. There’s no proactive monitoring, no alerts, no dashboards, and tracking a problem down takes hours.

4. Tight Coupling

Systems depend on each other directly, so one change ripples across every integration. Connections get wired up with no middleware or abstraction layer in between.

5. Neglecting Security

API keys are stored in code, HTTP is used instead of HTTPS, and authentication is weak. The risks of data leakage and unauthorized access get waved away.

6. Lack of Documentation

Integration flows, data mapping rules, and error codes were never written down. When a developer moves on, the knowledge walks out with them and maintenance turns painful.

7. Going Live Without a Test Environment

Integrations get tested straight in production. Errors hit real data, and rolling back is both hard and expensive.

Most of these are avoided by careful planning up front

Error Management and Retry Strategies

Errors are a given in integration systems. The job isn’t to avoid them entirely but to build the mechanisms that keep them from doing damage.

Retry Strategies

1. Fixed Interval

The same wait after each failed attempt (e.g., 30 seconds). Simple, but it can pile more pressure on a target system that’s already struggling.

2. Exponential Backoff

The wait grows exponentially with each attempt (1s, 2s, 4s, 8s…). Gives the target system room to breathe.

3. Exponential Backoff + Jitter

Adds a bit of randomness to the wait, so you don’t get dozens of clients retrying in lockstep.

Circuit Breaker Pattern

When the target system keeps returning errors, it stops requests for a while:

• Closed: Normal operation, requests are passed through
• Open: Error threshold exceeded, requests are blocked
• Half-Open: Test requests are sent, recovery is checked

Dead Letter Queue (DLQ)

Messages that exhaust every retry get moved to a separate queue (the DLQ). From there they are:

• Held for manual review
• Subjected to recovery processes
• Stored for analysis

Idempotency

Running the same transaction more than once shouldn’t change the result. How do you guarantee that?

• A unique ID (UUID) is assigned to every message
• The ID is checked before processing
• If it has already been processed, the result is returned directly

Monitoring and Alert Systems

Integration systems need watching 24/7. You want to catch problems before your users do.

Metrics to Monitor

Transaction Metrics

• Total transaction count (by minute/hour/day)
• Success/failure transaction ratio
• Average transaction duration (latency)
• Queue depth

System Metrics

• CPU, memory, disk usage
• Network I/O
• Connection pool status

Business Metrics

• Number of processed orders/invoices
• Data consistency ratios
• SLA compliance rates

Alert Strategy

• Critical (P1): Transaction success rate dropped below 95% – instant notification
• High (P2): Latency is 2x normal – notification within 15 minutes
• Medium (P3): Accumulated messages in DLQ – hourly summary
• Low (P4): Capacity warnings – daily report

Dashboards and Visualization

Build dashboards that show integration health at a glance:

• Traffic map (which systems are talking)
• Error distribution (by system, type, time)
• Trend graphs (transaction volume, error rate)
• SLA tracking table

Integration Success Metrics

Keep the following metrics handy for gauging the health of your integration architecture (representative values):

Integration Architecture Checklist

For a custom integration architecture design for your project, you can reach out via the contact page.

Frequently Asked Questions (FAQ)