Cache Architecture

The GrowthPath Application Server’s cache is the core technical advantage of the platform. It stores an up-to-date copy of Cin7 Core’s data in a high-performance database that offers both traditional SQL and modern JSON data processing.

Why Caching Matters

A naive integration calls the Cin7 Core API each time it needs information. This approach has fundamental limitations:

1. Rate limits — The Cin7 Core API has request limits that constrain throughput.
2. Redundant requests — Multiple integrations often retrieve the same data repeatedly.
3. Latency — Each API round-trip adds delay, which compounds in complex workflows.
4. Query limitations — The Cin7 Core API does not support advanced queries (e.g., “find all orders for the past 12 months involving a particular SKU sold from a particular location to a certain customer”). A naive integration must load every order and iterate.

The cache solves all of these problems.

Architecture

The Cin7 Core cache is a collection of JSON records that are straight from Cin7 Core’s API. They are stored in PostgreSQL using its JSON processing capabilities, enabling both:

• Traditional SQL queries for structured analysis
• JSON path queries for complex, nested data retrieval directly against the cached records

Data Flow

Cin7 Core API ──→ Cache Sync Workers ──→ PostgreSQL (JSON records)
                                              │
                                              ├── SQL queries
                                              ├── JSON path queries
                                              └── Integration code library

Multi-API Connection Support

For very high-volume sites, the cache can distribute its API load over multiple Cin7 Core API connections. This effectively multiplies the rate limit ceiling. Sites that are not yet ready for Cin7 Core’s dedicated server options can use this feature to handle significantly higher throughput.

Multi-Instance Consolidation

Some larger clients use multiple instances of Cin7 Core — potentially in different currencies. The cache brings this data together into a single queryable store. This is particularly valuable for consolidated reporting and cross-instance workflows.

Cache Synchronisation

The cache is continuously synchronised with Cin7 Core. Sync workers run as background processes within the Kubernetes namespace, pulling updated records on a configurable schedule.

The cache has been widely deployed and is very robust after years of production use. It contains many tweaks and optimisations developed from real-world high-volume deployments.

Querying the Cache

Integration code on the Application Server queries the cache directly rather than making live API calls. This enables:

• Complex queries that are impossible via the Cin7 Core API (e.g., multi-criteria order searches, cross-instance lookups)
• Sub-second response times for queries that would take minutes via the API
• Consistent data — all integrations see the same snapshot

Example: Examining a Cached Sale Object

The cached records are accessible through Django’s admin interface for debugging and inspection. Each record preserves the full JSON structure as returned by Cin7 Core.

Building Blocks

The code library has many building blocks based on the cache. Examples:

• Complex order splitting across multiple fulfilments and locations based on optimisation logic
• Auto-picking orders based on stock availability, including handling assembly of auto-assemble BOMs
• Backorder filling when stock becomes available
• Advanced allocation logic with soft and hard allocations to prevent order starvation

These building blocks combine the cache (for reading data) with the low-level Cin7 Core API wrappers (for writing data and executing business workflows).