From Live to VOD to AI Analysis: Building Sports OTT Platform POCHAK for What Comes Next
- 17 hours ago
- 7 min read
When a service ties together live streaming, VOD, and AI analysis, the architecture and operations behind it have to be ready from the very start.
- Jungyeop Jang, Technical Director, OTT platform, Hogak
[ 💡 Key Takeaways ]
1. Cut DB CPU usage to ~16% — laying a stable operational foundation for a media service that runs live streaming and VOD in parallel.
2. Resolved 5xx errors and NLB target group issues, from root-cause analysis to structural fixes — shifting from reactive firefighting to proactive operations.
3. Mapped an AI video-analysis roadmap by evaluating GPU workloads and Auto Scaling — preparing the next stage for sports media.
Hogak Inc.,
Company Hogak Inc.
Industry AI sports media & OTT platform
Founded May 3, 2024
Website pochak.live
Hogak Inc. is a sports media company that delivers AI camera-based live sports streaming and VOD through its service, POCHAK. From amateur leagues and clubs to elite sports, Hogak connects a wide range of venues to the digital world, making it easier to capture and watch the moments that matter on the field.
Hogak is doing more than broadcasting video. With AI camera-based automatic filming, post-game VOD, and AI video analysis on the horizon, the company is steadily expanding its service — while building the technical foundation to reach more users and more sports.
Preparing the Next Stage of Sports OTT
POCHAK isn’t a typical video platform. AI cameras spin up live channels automatically according to the game schedule, and once a match ends, that footage flows straight into VOD — turning the act of recording and broadcasting a sporting event into a single, connected experience.
The hard part was never simply “getting the service live.” Live and VOD run in parallel, traffic spikes with the season, and operational stability translates directly into user experience,. Layer planned AI video analysis on top of that, and the early architecture and operating model needed to be far more deliberate.
Hogak was gradually bringing its previously offshore-platform-dependent setup in-house, consolidating services and hardening operations along the way. That’s when a focused review began: which AWS-based structure fit best, and which partner should help put the operating mode in place.
Why Did Hogak Go AWS-First from the Start?
Hogak was working to align its existing and new services under one direction. On the infrastructure side, the team favored an AWS-based setup — and once media workloads and future scalability entered the picture, AWS made even more sense.
From the earliest stages, the architecture brought together EKS, RDS, Redis, API Gateway, WAF, Load Balancer, and Wowza. On top of that, it had to account for ISMS-grade security and networking, back-office access through a bastion host, and the possibility of expanding overseas.
In short, this was never about standing up a single service. It was about designing a structure that could run live streaming and VOD reliably while still absorbing future feature growth and international expansion.
Q. What mattered most to Hogak at the time?
Three things stood out for us. First, we needed an infrastructure setup realistic enough to hit our launch date. Second, because media services are sensitive to outages and latency, operational stability was critical. Third, with AI video analysis on the roadmap, the current structure had to be able to scale in that direction.
Working on day one simply wasn't enough — we needed a foundation that could hold up through ongoing operations and future growth.
Rethinking Operations, Together with SmileShark
From the first conversations, SmileShark helped define the architecture in AWS terms and worked through requirements alongside both the development team and Hogak. Rather than just listing “which services to use,” the approach centered on what could actually go wrong in production — and how to prepare for it.
As the service moved into launch and live operation, the collaboration widened: MSP support scope, technical inquiries, Site-to-Site VPN setup, cost and operations optimization reports, monitoring and alerting, and handling event-driven traffic.
Hogak’s traffic peaks are relatively predictable, but sports schedules can still trigger sudden load. SmileShark factored that in, separating short-term responses from longer-term improvements. Ahead of a large event, for example, the focus was on adjusting database specs and supporting operational monitoring; afterward, the work shifted to phased tasks like database tuning, structural improvements, and migration.
Connecting Live, VOD, and AI Analysis in One Flow
Hogak’s environment is far more complex than a standard web service. A live media flow, post-game VOD upload and distribution and eventually AI video-analysis results all have to mesh within a single pipeline.
With that in mind, SmileShark reviewed the media delivery flow, CloudFront (CDN) usage, S3 upload structure, the encoding process, EKS-based service operations, and load balancer (NLB/ALB) management. Looking ahead to analysis features, it also provided guidance — from an AWS perspective — on GPU instance usage, Auto Scaling, and batch versus real-time processing scenarios.
AI video analysis isn’t a problem you solve by simply adding a GPU instance. You have to decide how compute is allocated the moment a user requests analysis, how to cut costs during idle time, and how to design the flow for storing and serving results. SmileShark compared options like SageMaker, EC2, AWS Batch, and Rekognition so Hogak could chosse the right direction for its service model.
Q. What technical challenges came up during operations?
The notable ones included database load, intermittent 5xx errors, NLB target group health-check failures, missing TLS, and some load balancers being managed manually outside of EKS.
Several were resolved through root-cause analysis and improvement guidance. The NLB target group issue, for instance, was traced to a Trusted Relationship misconfiguration in the IAM role tied to aws-load-balancer-controller — fixing it restored a healthy state. For the 5xx errors, we examined application keyring issues, session-cookie decryption failures, and possible connection-flow anomalies, then established a log-based approach to tracing root causes alongside application restarts.
Q. What was most important as you hardened operations with SmileShark?
In the operations phase, the point isn’t to respond once when something breaks. The key is improving the structure so the same kind of problem doesn’t recur — and making it easier for operators to see what’s happening.
For Hogak’s environment, SmileShark recommended ways to raise operational visibility and consistency: EKS control-plane access, detailed logging, declarative load balancer management, TLS, cleanup of unused resources, and consolidated management of resources running outside EKS.
In 2026, an EKS optimization document laid out the state of multiple clusters across dev, staging, and production along with ALB/NLB operations, and proposed consolidated management via the AWS Load Balancer Controller plus HTTPS. Beyond strengthening security, the value was in reducing the chance of operational error and managing costs more efficiently.
What Operational Stability Changed
For a real-time media service, what happens after launch matters more than the launch itself. As Hogak gained experience with real traffic and user behavior, it stopped treating issues as one-off fixes and started reshaping the structure so problems wouldn’t return. The results showed up in the operational metrics..
Results at a Glance
Area | Before | After |
|---|---|---|
DB GPU usage | High load straining operations | Optimized to about 16% through phased tuning |
5xx errors / page disconnections | Recurring at certain points | Resolved as of March 2026 |
NLB target group health checks | Failures risking outages | Restored to healthy after IAM role fix |
TLS/HTTPS | Gaps in coverage | Strengthened with a defined rollout |
Load balancer management | Manual, outside EKS | Consolidated and declarative via the controller |
The real shift wasn’t just “the problems got fixed.” It was that the operating model itself moved from reacting after an outage to managing system state proactively. As operators gained better visibility, the odds of the same issues recurring dropped as well.
Three Things That Matter When Running Live, Media, and AI Services
1. Operations should be ready before launch, not after.
With a real-time media service, the period after go-live is where it counts. Incident response, logging, alerting, access control, and deployment all need to be designed in from the start to keep service quality intact.
2. For seasonal traffic, prepare ahead rather than react in the moment.
When traffic is predictable — tied to events or game schedules — capacity planning and monitoring beforehand beat scrambling after a spike.
3. For AI features, infrastructure design matters as much as model accuracy.
GPU workloads are expensive and operationally complex. Whether processing is real-time or batch, and how you trim idle resources, all have to be considered for it to work as a real service.
Why Hogak Recommends SmileShark
Q. What impressed you most about working with SmileShark?
More than just answering technical questions, SmileShark helped us work through the right technical decisions at each stage of growth. From AWS architecture reviews to production issue analysis, EKS and load balancer optimization, and AI workload evaluation — it was an approach that never separated building from operating, but considered operations from the very beginning.
Q. When would you recommend SmileShark to other companies?
It’s a strong fit for teams adopting AWS for the first time, running media or real-time workloads, or building something like AI video analysis where GPU and cost structure have to be designed together. When media and AI expansion overlap, knowing a single service well isn’t enough — you need architecture, operations, security, scalability, and cost weighed together, with the flexibility to reprioritize as real issues emerge.
Not the End, but the Next Step for AI Sports Media
Hogak isn’t content to simply keep its sports OTT service running smoothly. It’s preparing the platform’s next stage by expanding into AI-powered video analysis — features like tennis motion analysis that deliver real added value to users.
Capabilities like these demand a fundamentally different approach, both technically and in terms of cost structure: GPU usage, Auto Scaling, analysis pipelines, and even billing models all have to be worked out together. Hogak is reviewing these step by step, aligning its service model with how the infrastructure is operated.
And as Hogak rolls out more AI cameras, activates services across sports seasons, expands through local governments, and eventually looks abroad, the service will face an ever-wider range of technical demands. An AWS-based media and AI architecture, backed by a solid operating model, can be the foundation that carries that growth.
SmileShark has worked alongside Hogak to firm up today’s stability and prepare for tomorrow — and both companies plan to keep shaping the path forward for advanced sports media and AI services together.
Pressure-Test Your Operations Before You Launch
The operational gaps you'll regret not catching before launch. Get out free AWS Architecture Review Checklist for live, VOD, and AI workloads — check seasonal traffic readiness, EKS and load balancer operations, an AI analysis cost structure before you go live.
