Pavel Szalbot

In brief

Since 2007 I have built and run one thing: the entire technology of an online retail business, from the servers in the rack to the checkout button. About twenty storefronts in six markets sell on it every day, and everything between a customer's click and a parcel at the door, including payments, warehouses, marketplaces and the company ERP, goes through code I wrote and infrastructure I operate. I design it, build it, and answer the phone when it breaks.

Below are fifteen things I have built and keep running, ordered roughly by how hard each is generally understood to be. Each has a one-line summary and a short story; the three dots under a story unfold the technologies involved, for those who want them. A keyword table is at the end.

What I have built and what I run

1. Ten years running a private OpenStack cloud

   The shops run on a cloud I own end to end. For about ten years they have lived in a colocated data center on servers I chose and racked, with storage that survives disk and node failures and virtual machines created in minutes, which keeps cost, data and uptime in our own hands. The first generation I assembled by hand from upstream OpenStack and upgraded in place for years; the current one is hyper-converged, so every node contributes compute and storage, and it is deployed with community tooling so the next upgrade is routine rather than a project.

   ···Technologies used

   OpenStack (Keystone, Glance, Placement, Nova, Neutron with OVN, Cinder, Heat, Magnum) on KVM; Ceph for block storage and S3-compatible object storage; first generation built with my own Ansible roles from upstream packages and upgraded in place across releases, current generation hyper-converged and deployed with kolla-ansible; IPMI, hardware and software RAID, SMART monitoring.

2. Networking: MLAG, BGP, VPNs, firewalls

   A cloud is only as good as the network under it, so this one is built so that no single cable, switch or router can take the shops down. Every server is attached to a pair of switches at once, the public address space is ours and announced by our own routers, sites are joined by encrypted links, and traffic for management, storage, tenants and the internet never shares a lane. Firewalls are generated from code, so every host gets exactly the rules its role needs and nothing more.

   ···Technologies used

   Mellanox Onyx switches with MLAG, LACP, jumbo frames and priority flow control; BGP announcing tenant networks out of OpenStack; VXLAN and Geneve overlays with OVN; AS 57081; public IPv4 /22 and IPv6 /29 with reverse DNS, dual stack; IPsec and WireGuard VPNs; VRRP router redundancy; stateful multi-zone firewalls generated from Ansible; MikroTik RouterOS and Juniper alongside.

3. Multi-tenant e-commerce platform since 2007

   One platform, built since 2007, runs some twenty storefronts in six markets from a single codebase: catalog and stock in several warehouses, checkout, invoicing, returns, wholesale ordering for business customers, marketing feeds and the admin that staff use all day. A new shop, country or currency is configuration, not a project. The hard parts got solutions of their own: orders are allocated across warehouses automatically, the busiest pages come from a cache that knows exactly when to refresh, and staff translate products and pages themselves without waiting for a release.

   ···Technologies used

   Python and Django with REST and GraphQL APIs; PostgreSQL, Redis, RabbitMQ with Dramatiq workers, Elasticsearch; multi-site routing by domain with per-site configuration; a Redis-backed QuerySet cache with precise invalidation; a cross-warehouse stock-reservation engine; category trees indexed for fast subtree queries; a distributed job lock; a database-backed translation framework.

4. Third-party integrations, owned end to end

   Most of what a shop does touches someone else's system: a bank, a carrier, a marketplace, the ERP. I take each of these from the provider's specification to a running, monitored integration. I read the spec, agree with the business what it must do, build it against the provider's sandbox with a stand-in of the partner in our test suite, take it live, and then watch it: failed callbacks, rejected feeds and reconciliation mismatches surface as alerts, not as customer complaints. When a provider retires an API, the integration is rebuilt before the deadline; several of the ones below have been through that already.

   ···Technologies used

   OpenAPI, REST and SOAP/WSDL specifications; OAuth 2; request signing (RSA/X.509, AWS SigV4); sandbox and certification runs; mock servers in CI; alerting through Prometheus and Sentry.

5. Payment gateways and bank reconciliation

   Customers pay by card, bank transfer, Apple Pay, Google Pay, Klarna or PayPal, and every one of those paths was built and is maintained by me. Card payments go through 3-D Secure, where the gateway demands cryptographically signed requests and I verify its signed answers, so nobody can fake a paid order. Bank transfers used to mean someone reading statements; now statements are fetched from three banks automatically and matched to orders, helped by a QR code on every invoice that customers scan to pay with the right reference. Unmatched payments show up in the admin, not at month end.

   ···Technologies used

   GP webpay with 3-D Secure (RSA request signing, X.509 response verification); GoPay with Apple Pay and Google Pay; PayU; Klarna; PayPal; bank statements from UniCredit (SWIFT MT940 over WebDAV), Česká spořitelna (OAuth API) and Fio; Czech QR payment codes.

6. Amazon and Allegro across API generations

   The shops also sell on Amazon and on Allegro, Poland's largest marketplace, without anyone retyping anything: listings, prices, stock, orders and refunds move between the platform and the marketplaces on their own. Both marketplaces have replaced their APIs since we started, and both integrations were rebuilt before the old ones were switched off. Smaller partners get the same care: price-comparison sites, Google Shopping, the newsletter service, SMS gateways and a student-card verification service.

   ···Technologies used

   Amazon SP-API with hand-written AWS SigV4 signing, migrated from MWS: orders, reports, feeds, catalog, pricing; Allegro REST API, migrated from the SOAP WebAPI: offer lifecycle, bulk price and stock commands, category and parameter sync, event-driven order intake; Heureka, Zboží.cz and Google Merchant Center feeds; Ecomail; SMS gateways; ISIC verification over SOAP.

7. ERP integration with SAP Business One

   The company keeps its books and its warehouse in SAP Business One, and the shops must never disagree with it about what is in stock, what it costs or what was invoiced. I built and maintain the bridge between the two: stock and prices flow from SAP to the shops; orders, delivery notes and warehouse transfers flow back; invoices are produced in SAP and handed to customers by the shop as PDF. A stand-in for SAP lives in the test suite, so every change is proven against it before it reaches production.

   ···Technologies used

   SAP Business One service layer and direct MSSQL queries; invoice XML and PDF; delivery notes; stock transfers; a mock SAP service in CI.

8. Logistics and the physical side of orders

   An order is only finished when the parcel arrives, so the platform speaks to twelve carriers: it quotes shipping, prints labels and lets customers choose a pickup point on a map that stays fast with thousands of points on it. It decides how an order splits into boxes, suggests valid addresses as customers type, and gives warehouse staff their own picking screens.

   ···Technologies used

   PPL, DPD, GLS, InPost, Zásilkovna/Packeta, Balíkovna, Česká pošta, DHL, UPS, Colissimo, WeDo, Orlen; live rate APIs from DHL and UPS; label printing; a parcel packing heuristic; k-means clustering of pickup points by zoom level; address suggestion on the Czech RÚIAN registry.

9. Search, catalog data and translations

   Customers shop in six languages with search tuned for product names, brands and sizes. Behind it is catalog data that is unusually deep for a shop: size tables that map between sizing systems, rules that know which snowboard fits which binding, and bidding rules that decide what a click from a price-comparison site is worth. New products are translated automatically into every language and reviewed by staff before they go live.

   ···Technologies used

   Elasticsearch 8 with custom analyzers for products and orders; size tables and size maps; product-set compatibility rules; rule-based CPC bidding for Heureka and Zboží.cz; DeepL and Google Translate feeding a review workflow; database-backed i18n in six languages.

10. Admin tools and storefront frontends

    The people who run the shops spend their days in the admin, so it is built for them: returns, vouchers, mass discounts, marketplace refunds, warehouse picking, statistics and translations each have a purpose-built screen instead of a generic form. A small framework of my own means a new screen is mostly about the workflow, not the plumbing. On the customer side, each brand has its own look on a shared foundation, so a fix lands in every shop at once.

    ···Technologies used

    Svelte 5 with TypeScript and Tailwind; React with MobX; a Svelte admin framework on Django (viewsets, filters, pagination); Vite-built storefront themes from shared sources; SCSS; Sentry in the browser.

11. CI/CD: from commit to rolling release

    A change travels from my editor to every storefront without a maintenance window. Each commit is built, checked and tested against a complete copy of the system, including stand-ins for SAP and the payment and marketplace partners, and the very image that passed the tests is what gets deployed, one host at a time, while the others keep serving. New containers announce themselves to the router the moment they start, so releases and scaling need no manual reconfiguration.

    ···Technologies used

    GitLab CI with base and application images, Ruff, ten parallel test jobs over Docker Compose with mock servers, combined coverage, container registry; Ansible rolling deployments; uWSGI fastrouter with instance subscriptions; Kubernetes where it earns its place (kubeadm, OpenStack Magnum, kind with the Elasticsearch and RabbitMQ operators).

12. Observability and on-call

    I know about problems before customers do. Every layer is watched, from fan speeds and disk health in the rack to the checkout page as a customer sees it, and alerts reach my phone. Logs from switches, routers and servers land in one place, so an incident is reconstructed in minutes rather than by guesswork. I have carried the pager for all of it, which is the strongest reason the system is built the way it is.

    ···Technologies used

    Prometheus and Alertmanager with Telegram and Discord; node, IPMI, SNMP, blackbox, PostgreSQL, Elasticsearch and Ceph exporters; VictoriaLogs fed by syslog and journald, previously ELK with Logstash pipelines; Grafana; Sentry; Elastic APM.

13. Supporting services run in-house

    The things a business normally rents are run in-house and automated: DNS for over a hundred domains, company mail, certificates that renew themselves, the databases and queues the shops depend on. Not for its own sake: a provider's outage is not our outage, and the bill and the data stay ours.

    ···Technologies used

    Knot DNS and PowerDNS (authoritative, with API); internal resolvers; DHCP; Postfix, Dovecot and rspamd with database-backed virtual domains; Let's Encrypt with acme-dns; PostgreSQL with streaming replication; Redis Sentinel; RabbitMQ.

14. Security

    Administrators sign in with passkeys, so there is no password to phish. Customer data can be exported or erased on request, as the GDPR requires. Deployment secrets live in an encrypted vault, every host exposes only the ports its role needs, and where money changes hands the messages are signed and verified. Security here is how the system is built, not a checklist at the end.

    ···Technologies used

    WebAuthn passkeys; Google Sign-In with JWT verification against Google's key set; reCAPTCHA; GDPR export and erasure tooling; Ansible Vault; per-service firewall rules; RSA/X.509 signing for payments; TLS everywhere.

15. AI in operations

    The business can ask the shop questions in plain language: what is selling, what is dead stock, what needs reordering before the season, how sizes sell across brands. I built the connector that lets AI assistants answer from live sales and stock data, with proper access control, so an analyst's afternoon becomes a two-minute conversation. I use AI assistants in my own work every day, with the context they need kept next to the code.

    ···Technologies used

    An MCP (Model Context Protocol) server with thirteen analytics tools built on FastMCP, served over stdio or HTTP with bearer-token auth; curated project context for AI-assisted development.

Any of the above can be shown running, or in code, on request.

Technical environment

Languages

• Czech / Slovak (native)
• English (professional)
• Polish (working knowledge)
• French (enthusiast)

Education

Faculty of Mathematics and Physics, Charles University, Prague