Four Tochki Orders Laravel Package

Technical Evaluation

What this package actually is (correct the premise first)

• Despite being framed as a Laravel/PHP package, the README install path is unambiguously Symfony: php bin/console baks:assets:install, Doctrine migrations via doctrine:migrations:*, PHPUnit groups, and a bundle-oriented asset pipeline. It is a module of the BaksDev framework (a Symfony-based B2B/CMS distribution), not a Laravel package.
• The package name says orders, the description says "Модуль продукции" (products module), and the README says "Модуль заказов" (orders module). Three conflicting scopes in three artifacts. We do not know, from public materials, what the bounded context is. This must be resolved before any estimate is credible.
• Scope of what we actually get: a Doctrine schema for order/product entities, asset/config install commands, and an integration surface toward the 4tochki marketplace. We get no documented API client contract, no webhook spec, no error taxonomy, and no public test evidence beyond a --group name.

Architecture fit

• Fit with a Laravel codebase: poor out of the box. Laravel has no bundle system, no bundle-registered Doctrine entity manager, and no bin/console. Adapting requires either a Symfony-bridge shim (spatie/laravel-symfony-components-style), a second ORM alongside Eloquent, or a fork.
• Fit with a Symfony/BaksDev codebase: good. If our platform is Symfony + Doctrine, this drops in with two commands. That is the only scenario where the ROI is clean. TPM action: confirm our target stack before scoping anything else.
• Fit as a reference implementation: high value, low cost. Even in a Laravel shop, the Doctrine entity definitions and migration files are the closest thing to a written 4tochki domain model we have. Reading and re-implementing is plausibly cheaper than bridging — see Integration Approach.
• Strategic fit is region- and channel-locked. 4tochki is a Russian tire-retail marketplace. This is only on the roadmap if CIS expansion is funded. If that is not a committed initiative, the correct decision is "no decision" — park it.

Integration feasibility

• Feasible if we accept a fork-and-own posture: extract the order/product schema and the 4tochki HTTP calls, re-express them as Laravel migrations + a service class + queued jobs. Moderate effort, fully under our control, no long-term dependency on a zero-traction vendor.
• Risky if we attempt transparent bridging: dual ORMs, dual event dispatchers, dual console kernels. This creates a permanent "two frameworks in one process" tax that every future engineer pays. I would not approve this path without an explicit owner and a sunset plan.
• Blocked pending discovery on: 4tochki API auth model, rate limits, idempotency keys, webhook signature scheme, and whether order state is push- or poll-driven. None of this is in the README.

Technical risk (rated for planning)

• Note on release metadata: the latest release is dated 2026-05-18, i.e. forward of typical current dates, and release notes for v7.4.3 and v7.4.2 are both literally the version string. Either the metadata is synthetic/mirrored or release hygiene is absent. Either way, release notes are not a signal of quality here — do not let "has releases" satisfy a diligence gate.
• MIT license is clean for commercial use and forking. That materially lowers the cost of the fork-and-own path and is the single strongest argument for engaging with this package at all.

Key questions I need answered before committing engineering

1. Stack: Is the consuming system Symfony/Doctrine or Laravel/Eloquent? If Laravel, is a fork acceptable, or is a bridge mandated?
2. Scope: Is this orders, products, or both? Which entity owns the order lifecycle?
3. Demand: Is 4tochki a committed channel with volume forecasts and an account/API credential in hand, or an exploratory bet? No credentials = no POC = no estimate.
4. Contract: Where is 4tochki's official API documentation, and does it define idempotency and webhook signing?
5. Ownership: Who is the named internal owner post-integration? A zero-dependency package cannot be adopted without one.
6. Precedent: Does the team already run any BaksDev modules? If yes, the calculus changes entirely in the package's favour.

Integration Approach

Stack fit — decide the path explicitly, do not drift into one

• Path A — Native Symfony/BaksDev host. Fit: excellent. Effort: low (days). Action: composer require, baks:assets:install, migration diff/migrate, then wire the order service into our fulfillment flow. This is the only path where the package is used as intended.
• Path B — Laravel host, fork-and-own (recommended if we are Laravel). Treat the package as a specification artifact, not a dependency. Harvest entity definitions and migrations, port to Laravel migrations + Eloquent models, wrap 4tochki calls in a single FourTochkiClient service behind an interface, drive state changes through queued jobs. Effort: medium (weeks), but no permanent dual-framework tax and no vendor dependency.
• Path C — Laravel host via Symfony bridge (not recommended). Highest complexity, highest ongoing cost, weakest justification. Only viable if Path B is blocked by a hard requirement to consume the package's internals verbatim.
• Whichever path: isolate every 4tochki-specific concern behind one internal interface (FourTochkiGateway) so the marketplace can be swapped for Wildberries/Ozon later without touching domain code. This is the cheapest optionality we will ever buy.

Migration path

• Never run vendor Doctrine migrations against a shared production schema. Generate the diff, review it line by line, and re-author as our own versioned migrations. Doctrine's diff output is not reviewed-safe by default.
• Schema isolation: put 4tochki tables in a distinct prefix or schema, with foreign keys pointing into our core tables, not the reverse. This keeps blast radius contained if we later rip the integration out.
• Data ownership: our core orders table remains the system of record. 4tochki data lands in a sync/landing layer with an explicit reconciliation job. Do not let an external marketplace own our order state machine.
• Config and secrets: API credentials in our existing secret store, not in the package's config files. The baks:assets:install step publishes config — audit what it writes and whether it emits anything sensitive.

Compatibility

• PHP 8.4 floor is a hard gate. If the host app is on 8.2/8.3, this initiative is coupled to a runtime upgrade — sequence it as a dependency in the plan, not a surprise in sprint 1.
• Doctrine vs. Eloquent is the primary incompatibility. Committing to two ORMs in one app is an architectural decision requiring explicit sign-off; I will not let it happen by default.
• Eventing: Symfony EventDispatcher semantics do not map onto Laravel events. Re-express as Laravel events + queued listeners so retries and observability come for free.
• Localization: expect Russian-only error strings. Budget a translation/error-mapping layer if any of this surfaces in operator-facing tooling.

Sequencing (stage-gated; do not skip gates)

1. Gate 0 — Diligence (1–2 days, ~0.25 eng). Read the source: entity map, HTTP client, tests, dependency tree, transitive licenses. Output: a one-page memo answering the Key Questions. Kill criterion: no reachable 4tochki API docs or no sandbox credentials.
2. Gate 1 — Spike (1 week, 1 eng). Single happy-path: create one order against a 4tochki sandbox from a throwaway branch. Output: latency numbers, auth model, error shapes, a go/no-go on Path A/B/C. Kill criterion: API access not obtainable, or auth requires a partner agreement we cannot sign.
3. Gate 2 — Thin slice (2–3 weeks). One product line, one direction (read-only order import preferred over write-back), behind a feature flag, shadow-mode only. No customer-visible effect.
4. Gate 3 — Pilot. Enable write-back and fulfillment actions for a limited catalogue. Reconciliation report runs daily and must reconcile to zero variance before widening.
5. Gate 4 — General availability. Only after two clean reconciliation cycles, a documented runbook, and a named owner.

• Deliberate recommendation: ship read-only before write. Importing orders is recoverable; pushing incorrect fulfillment actions to a live marketplace is not. This ordering is the cheapest risk reduction available and should be treated as non-negotiable.

Operational Impact

Maintenance

• Assume we own this code from day one. Zero stars, zero dependents, and a single maintainer means upstream fixes are not a plan. Budget a standing maintenance allocation (order of a few eng-days per quarter) for API drift and security patching, and record it in the capacity plan — not in a wiki nobody reads.
• Fork discipline: if we fork, tag our fork, keep a changelog of divergences from upstream, and decide now whether we ever re-base. "Fork and forget" is acceptable; "fork and pretend we'll sync" is how teams accumulate mystery code.
• Dependency footprint: the bundle drags Symfony components and Doctrine into the tree. On a Laravel host this is pure weight with no runtime benefit under Path B (which is another argument for Path B over Path C).

Support

• There is no support channel. No issue tracker activity, no community, no vendor SLA. Escalation path is: our owner → 4tochki's own developer support → re-implement. Communicate this plainly to stakeholders so nobody assumes a vendor relationship exists.
• Error surface is unmapped. We do not know how the package translates 4tochki API failures. Build our own exception taxonomy and alerting at the gateway boundary rather than trusting wrapped exceptions.
• Documentation debt is ours. The README covers installation and nothing else. A short internal runbook (how to create an order, how to reconcile, how to rotate credentials, how to disable the integration) is a launch prerequisite, not a nice-to-have.

Scaling

• Rate limits are the binding constraint, and they are unknown. Design for the pessimistic case: token-bucket throttling at the gateway, queue-based dispatch, exponential backoff with jitter, and dead-letter queues. Retrofitting throttling after a marketplace ban is far more expensive than building it in.
• Stateless order calls scale horizontally without issue. The real scaling risk is webhook ingestion — bursts during promotions. Isolate webhook handling on a dedicated queue with its own worker pool so a marketplace spike cannot starve core application jobs.
• Database: 4tochki tables will be write-heavy and read-light during sync. Keep them out of hot paths, cache reference data (products, prices) in Redis rather than joining across the boundary on every request.

Failure modes and mitigations

• Silent failure is the dominant risk profile here, not loud failure. The integration's worst outcome is orders quietly not arriving. Instrument sync lag, backlog depth, and reconciliation variance as first-class SLOs with alerting — not dashboards.

Ramp-up

• Learning curve is dual: Symfony internals (container, EventDispatcher, console) plus 4tochki's order/payment lifecycle. Under Path A both are unavoidable; under Path B the Symfony half largely disappears, which is a real onboarding-cost argument for forking.
• Staffing: one engineer with Symfony/Doctrine fluency for the spike and slice; a second reviewer for the migration and reconciliation design. Do not staff this with someone learning Doctrine and the marketplace simultaneously.
• Onboarding assets to produce before GA: (1) one-page architecture diagram showing the gateway boundary, (2) runbook covering create/reconcile/rotate/disable, (3) recorded API fixtures so the team can work without sandbox access, (4) a "how to remove this integration in a day" note — the removal plan is the best proof the boundary is real.
• Stakeholder framing I would use: "This is a niche marketplace module with no community and no vendor support. It is worth two weeks of diligence because the MIT license means we can own the code outright if the channel is real. We gate it hard: read-only first, shadow-mode before write-back, and we do not commit platform runtime upgrades to it. If the POC fails, the sunk cost is one engineer-week — which is cheaper than the alternative of discovering a framework mismatch three months in."

Bottom line for the roadmap decision

• Conditional go, gate 0 first. The package is only a good deal if (a) the host is Symfony/BaksDev, or (b) we are prepared to fork and own it in Laravel, and (c) 4tochki is a funded channel with credentials obtainable.
• If the host is Laravel and a bridge is mandated → recommend no-go and re-scope against 4tochki's official API directly. The package's real deliverable to us in that scenario is the domain model, and we can read that for free.